Felsöka tillfälliga tidsgränser för anslutning mellan tillgänglighetsgrupprepliker

Den här artikeln hjälper dig att diagnostisera tillfälliga tidsgränser för anslutningar som rapporteras mellan tillgänglighetsgrupprepliker.

Symptom och effekter av tillfälliga tidsgränser för tillgänglighetsgruppsreplikanslutning

Att köra frågor mot primära och sekundära repliker returnerar olika resultat

Skrivskyddade arbetsbelastningar som kör frågor mot sekundära repliker kan köra frågor mot inaktuella data. Om tidsgränsen för tillfälliga replikeringsanslutning inträffar återspeglas inte ändringar i data i den primära replikdatabasen ännu i den sekundära databasen när du frågar samma data. Mer information finns i avsnittet Datasvarstid på sekundär replik .

Tillgänglighetsgruppen för diagnostikrapporter har inte synkroniserats

Instrumentpanelen AlwaysOn i SQL Server Management Studio kan rapportera en tillgänglighetsgrupp med feltillstånd som har repliker som inte synkroniseras . Du kan också se att rapportreplikerna för AlwaysOn-instrumentpanelen är i läget Inte synkroniserad .

När du granskar SQL Server-felloggarna för dessa repliker kan du observera meddelanden som följande som anger att det fanns en tidsgräns för anslutningen mellan replikerna i tillgänglighetsgruppen:

Fellogg från den primära repliken

2023-02-15 07:10:55.500 spid43s Always On availability groups connection with secondary database terminated for primary database 'agdb' on the availability replica 'SQL19AGN2' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Fellogg från den sekundära repliken

2023-02-15 07:11:03.100 spid31s A connection time-out has occurred on a previously established connection to availability replica 'SQL19AGN1' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

2023-02-15 07:11:03.100 spid31s Always On Availability Groups connection with primary database terminated for secondary database 'agdb' on the availability replica 'SQL19AGN1' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Tillfälliga anslutningsproblem kan påverka redundansberedskapen för en sekundär replik

Om du konfigurerar tillgänglighetsgruppen för automatisk redundans och den synkrona incheckningspartnern tillfälligt kopplas från den primära, kan automatisk redundans misslyckas.

Du kan fråga sys.dm_hadr_database_replia_cluster_states för att avgöra om tillgänglighetsgruppens databas är redundansklar just då. Här är ett exempel på resultatet om speglingsslutpunkten stoppades på den sekundära repliken:

SELECT drcs.database_name, drcs.is_failover_ready, ar.replica_server_name, ars.role_desc, ars.connected_state_desc,
ars.last_connect_error_description, ars.last_connect_error_number, ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ars.replica_id=ar.replica_id
JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ar.replica_id=drcs.replica_id
WHERE ars.role_desc='SECONDARY'

Automatisk redundans kanske inte gör tillgänglighetsgruppen online i den primära rollen på redundanspartnerdatorn om redundansväxlingen sammanfaller med tidsgränsen för replikanslutningen.

Vad indikerar timeout-felen för anslutningen?

Standardvärdet är 10 sekunder för tillgänglighetsgruppens replikinställning, SESSION_TIMEOUT. Den här inställningen har konfigurerats för varje replik. Den avgör hur länge repliken väntar på att få ett svar från partnerrepliken innan den rapporterar en tidsgräns för anslutningen. Om en replik inte får något svar från partnerrepliken rapporterar den en tidsgräns för anslutningen i Microsoft SQL Server-felloggen och Windows-programloggen. Repliken som rapporterar tidsgränsen försöker omedelbart återansluta och fortsätter att försöka var femte sekund.

Vanligtvis identifieras tidsgränsen för anslutningen och rapporteras endast av en replik. Tidsgränsen för anslutningen kan dock rapporteras av båda replikerna samtidigt. Det finns olika versioner av det här meddelandet, beroende på om tidsgränsen för anslutningen uppstod med hjälp av en tidigare upprättad anslutning eller en ny anslutning:

Message 35206 A connection timeout has occurred on a previously established connection to availability replica '<replicaname>' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

Message 35201 A connection timeout has occurred while attempting to establish a connection to availability replica '<replicaname>' with id [<replicaid>]. Either a networking or firewall issue exists, or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Partnerrepliken kanske inte identifierar en tidsgräns. Om den gör det kan den rapportera meddelande 35201 eller 35206. Om den inte gör det rapporterar den en anslutningsförlust för var och en av tillgänglighetsgruppdatabaserna:

Message 35267 Always On Availability Groups connection with primary/secondary database terminated for primary/secondary database '<databasename>' on the availability replica '<replicaname>' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Här är ett exempel på vad SQL Server rapporterar till felloggen: Om du stoppar speglingsslutpunkten på den primära repliken identifierar den sekundära repliken en tidsgräns för anslutningen och meddelandena 35206 och 35267 rapporteras i den sekundära replikfelloggen:

2023-02-15 07:11:03.100 spid31s A connection timeout has occurred on a previously established connection to availability replica 'SQL19AGN1' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

2023-02-15 07:11:03.100 spid31s Always On Availability Groups connection with primary database terminated for secondary database 'agdb' on the availability replica 'SQL19AGN1' with Replica ID:[<replicaid>]. This is an informational message only. No user action is required.

I det här exemplet identifierade den primära repliken inte någon tidsgräns för anslutningen eftersom den fortfarande kunde kommunicera med den sekundära repliken och den rapporterade meddelande 35267 för varje tillgänglighetsgruppdatabas (i det här exemplet finns det bara en databas, "agdb"):

2023-02-15 07:10:55.500 spid43s Always On Availability Groups connection with secondary database terminated for primary database 'agdb' on the availability replica 'SQL19AGN2' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Orsaker till tidsgränser för replikanslutning

Programproblem

SQL Server kan vara upptagen av någon av flera orsaker och betjänar inte speglingsslutpunktsanslutningen inom tillgänglighetsgruppens SESSION_TIMEOUT period. Detta orsakar tidsgränsen för anslutningen. Några av följande orsaker är:

• SQL Server har 100 procent cpu-användning. Det innebär att SQL Server eller något annat program kör CPU i sekunder i taget.

• SQL Server har icke-givande scheduler-händelser. SQL Server-trådar ansvarar för att ge schemaläggaren (CPU) till andra trådar för att slutföra sitt arbete om en tråd inte ger i rätt tid.

• SQL Server upplever arbetstrådsöverbelastning, minnesbrist eller programproblem som påverkar dess förmåga att betjäna speglingsslutpunktsanslutningen.

Nätverksproblem

Detta kräver att du samlar in nätverksspårningsloggar på de primära och sekundära replikerna när felet utlöses. För att göra detta kan du undersöka nätverksfördröjning och borttagna paket.

Så här diagnostiserar du tidsgränser för replikanslutning

För problem med programproblem som hindrar SQL Server från att underhålla anslutningen med partnerrepliken förklarar det här avsnittet hur du analyserar SQL Server-loggarna. De här tipsen kan hjälpa dig att identifiera rotorsaken till tidsgränserna för replikanslutningen. Det här avsnittet slutar med mer avancerad vägledning om hur du samlar in nätverksspårningar när tidsgränsen för anslutningen inträffar så att du kan kontrollera nätverksstatusen.

Utvärdera tidpunkt och plats för tidsgränser för replikanslutning

Granska historiken, frekvensen och trenderna för tidsgränserna för anslutningen. Att använda de meddelanden som du hittar i SQL Server-felloggen är ett bra sätt att göra detta på. Var rapporteras tidsgränserna för anslutningen? Rapporteras de konsekvent på den primära eller sekundära repliken? När inträffade felen? Inträffade de under en viss vecka i månaden, veckodag eller tid på dagen? Motsvarar annat schemalagt underhåll eller batchbearbetning de tidpunkter då tidsgränsen för anslutningen observerades? Den här utvärderingen kan hjälpa dig att begränsa och korrelera tidsgränserna för anslutningen för att identifiera rotorsaken.

Granska den AlwaysOn_health utökade händelsesessionen

Den AlwaysOn_health utökade händelsesessionen ucs_connection_setup har utökats för att inkludera händelsen, som utlöses när en replik upprättar en anslutning till sin partnerreplik. Detta kan vara användbart när du felsöker problem med tidsgränser för anslutningar.

Fråga Always On Distributed Management Views (DMV:er)

Du kan fråga Always On DMV:er om du vill ha mer information om replikens anslutna tillstånd. Den här frågan rapporterar endast det anslutna tillståndet och eventuella fel som är associerade med tidsgränsen för anslutningen när problemen uppstår. Om anslutningsproblemen är tillfälliga kanske frågan inte enkelt avbildar det frånkopplade tillståndet.

SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc,
ars.last_connect_error_description, ars.last_connect_error_number, ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ars.replica_id=ar.replica_id

I följande exempel visas ett ihållande frånkopplat tillstånd eftersom speglingsslutpunkten på den primära repliken stoppades. Genom att fråga den primära repliken kan ALWAYSOn DMV rapportera om de primära och alla sekundära repliker (slutpunkten är inaktiverad på den primära repliken).

Genom att fråga den sekundära repliken rapporterar AlwaysOn DMV:er endast på den sekundära repliken.

Granska den utökade händelsesessionen Always On

1. Anslut till varje replik med hjälp av SQL Server Management Studio -objektutforskaren (SSMS) och öppna de utökade händelsefilerna AlwaysOn_health .

2. I SSMS går du till Öppna fil>och väljer sedan Sammanfoga utökade händelsefiler.

3. Välj knappen Lägg till.

4. I dialogrutan Öppna fil navigerar du till filerna i KATALOGEN SQL Server \LOG.

5. Tryck på Kontroll och välj sedan de filer vars namn börjar med "AlwaysOn_healthxxx.xel".

6. Välj Öppna och välj sedan OK.

   Du bör se ett nytt fönster med flikar i SSMS som visar AlwaysOn-händelserna.

   Följande skärmbild visar AlwaysOn_health data från den sekundära repliken. Den första dispositionsrutan visar anslutningsförlusten efter att slutpunkten på den primära repliken har stoppats. Den andra dispositionsrutan visar anslutningsfelet som inträffar nästa gång den sekundära repliken försöker ansluta till den primära repliken.

   

Kontrollera om icke-avkastningshändelser orsakar tidsgränser för anslutning

En av de vanligaste orsakerna till att en tillgänglighetsreplik inte kan betjäna partnerreplikanslutningen är en icke-avkastningsschemaläggare. Mer information om icke-avkastningsschemaläggare finns i Felsöka SQL Server-schemaläggning och avkastning.

SQL Server spårar icke-givande scheduler-händelser som är så korta som 5 till 10 sekunder. Den rapporterar dessa händelser i TrackingNonYieldingScheduler datapunkten i komponentens sp_server_diagnostics query_processing utdata.

Följ dessa steg för att söka efter icke-avkastningshändelser som kan orsaka tidsgränser för replikanslutning:

1. Skapa ett SQL Agent-jobb som registrerar sp_server_diagnostics var femte sekund.

2. Schemalägg det här jobbet på servern som inte rapporterar tidsgränsen för anslutningen. Om Server A-repliken rapporterar tidsgränsen för replikanslutningen i felloggen konfigurerar du SQL Agent-jobbet på partnerrepliken Server B. Om du ser tidsgränser för anslutningen på båda replikerna kan du skapa jobbet på båda replikerna.

3. Kör följande batchfil för att skapa ett jobb som körs sp_server_diagnostics var femte sekund, lägger till utdata i en textfil och startar sedan jobbet. Kommandot i följande exempel sp_server_diagnostics 5 körs var femte sekund. Det finns därför inget behov av att schemalägga det här jobbet så att det körs var femte sekund, starta bara jobbet och det körs tills det stoppas, var femte sekund:

   USE [msdb]
   GO
   DECLARE @ReturnCode INT
   SELECT @ReturnCode = 0
   DECLARE @jobId BINARY(16)
   EXEC @ReturnCode = msdb.dbo.sp_add_job @job_name=N'Run sp_server_diagnostics',
   @owner_login_name=N'sa', @job_id = @jobId OUTPUT
   /****** Object: Step [Run SP_SERVER_DIAGNOSTICS] Script Date: 2/15/2023 4:20:41 PM ******/
   EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Run SP_SERVER_DIAGNOSTICS',
   @subsystem=N'TSQL',
   @command=N'sp_server_diagnostics 5',
   @database_name=N'master',
   @output_file_name=N'D:\cases\2423\sp_server_diagnostics_output.out',
   @flags=2
   EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
   EXEC sp_start_job 'Run sp_server_diagnostics'
   

   Kommentar

   I de här kommandona ändrar du @output_file_name till en giltig sökväg och anger ett filnamn.

Analysera resultaten

När tidsgränsen för anslutningen rapporteras bör du notera tidsstämpeln för timeout-händelsen som visas i SQL Server-felloggen. För replikerna i följande exempel SQL19AGN1 rapporterades tidsgränserna för replikanslutningen. Därför skapades ett SQL Agent-jobb på SQL19AGN2partnerrepliken. Därefter rapporterades en timeout för anslutningen i felloggen SQL19AGN1 kl. 07:24:31.

Därefter kontrolleras utdata från SQL Agent-jobbet som körs sp_server_diagnostics vid den rapporterade tidpunkten TrackingNonYieldingScheduler , särskilt genom att granska datapunkten i komponentens query_processing utdata. Utdata rapporterar att en icke-avkastningsschemaläggare spårades (som ett hexadecimalt värde som inte är noll) på servern SQL19AGN2 (kl. 07:24:33) ungefär samtidigt som tidsgränsen för replikanslutningen rapporterades på SQL19AGN1 (kl. 07:24:31).

Undersöka en icke-givande scheduler-händelse

Om du från de tidigare diagnosstegen har verifierat att en händelse som inte gav resultat orsakade tidsgränsen för replikanslutningen:

1. Identifiera de arbetsbelastningar som körs i SQL Server vid den tidpunkt då icke-avkastningshändelser körs.

2. På samma sätt som tidsgränserna för replikanslutningen letar du efter trender i dessa händelser under den månad, dag eller vecka som de inträffar.

3. Samla in spårning av prestandaövervakare i systemet där den icke-avkastningshändelsen identifierades.

4. Samla in nyckelprestandaräknare för systemresurser, inklusive processor::% processortid, minne::Tillgängliga MByte, logisk disk::Genomsnittlig diskkölängd och logisk disk::Genomsnittlig disk sek/överföring.

5. Om det behövs öppnar du en SQL Server-supportincident för ytterligare hjälp med att hitta rotorsaken till dessa icke-avkastningshändelser. Dela loggarna som du har samlat in för ytterligare analys.

Avancerad datainsamling: Samla in nätverksspårning under tidsgränsen för anslutningen

Om den tidigare diagnosen av SQL Server-programmet inte gav någon rotorsak bör du kontrollera nätverket. En lyckad analys av nätverket kräver att du samlar in en nätverksspårning som täcker tiden för tidsgränsen för anslutningen.

Följande procedur startar en Windows-nätverksspårning netsh på replikerna där tidsgränserna för anslutningen rapporteras i SQL Server-felloggarna. En schemalagd händelseaktivitet i Windows utlöses när ett av SQL Server-anslutningsfelen registreras i programloggen. Den schemalagda aktiviteten kör ett kommando för att stoppa nätverksspårningen netsh så att nyckelnätverksspårningsdata inte skrivs över. De här stegen förutsätter också en sökväg till *F:* för batch- och spårningsloggarna. Justera den här sökvägen till din miljö.

1. Starta en nätverksspårning, som du ser i följande kodfragment, på de två repliker där tidsgränsen för anslutningen inträffar:

   netsh trace start capture=yes persistent=yes overwrite=yes maxsize=500 tracefile=f:\trace.etl
   

2. Skapa schemalagda Windows-aktiviteter som stoppar spårningen av netsh händelser 35206 eller 35267. Du kan skapa dessa uppgifter på en administrativ kommandorad:

   schtasks /Create /tn Event35206Task /tr F:\stoptrace.bat /SC ONEVENT /EC Application /MO *[System/EventID=35206] /f /RL HIGHEST
   
   schtasks /Create /tn Event35267Task /tr F:\stoptrace.bat /SC ONEVENT /EC Application /MO *[System/EventID=35267] /f /RL HIGHEST
   

3. När händelsen inträffar och nätverksspårningarna stoppas och registreras kan du ta bort uppgifterna ONEVENT :

   PS C:\Users\sqladmin> Schtasks /Delete /tn Event35206Task /F
   PS C:\Users\sqladmin> Schtasks /Delete /tn Event35267Task /F
   

Analysen av nätverksspårningen ligger utanför den här felsökarens omfång. Om du inte kan tolka nätverksspårningen kontaktar du Microsoft SQL Server-supportteamet och anger spårningen tillsammans med andra begärda loggfiler för rotorsaksanalys.

Vad mer kan jag göra för att minska tidsgränserna för anslutningen?

Standardtillgänglighetsgruppen, SESSION_TIMEOUT, är konfigurerad i 10 sekunder. Du kanske kan minska tidsgränsen för anslutningen genom att justera tillgänglighetsgruppens replikegenskap SESSION_TIMEOUT . Den här inställningen är per replik. Justera den för den primära och varje berörd sekundär replik. Här är ett exempel på syntaxen. SESSION_TIMEOUT Standardvärdet är 10. Därför kan du använda 15 som nästa värde.

ALTER AVAILABILITY GROUP ag
MODIFY REPLICA ON 'SQL19AGN1' WITH (SESSION_TIMEOUT = 15);