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 timeouter 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 fråga efter inaktuella data. Om tidsgränsen för tillfälliga replikeringsanslutningar inträffar återspeglas ännu inte ändringar i data i den primära replikdatabasen i den sekundära databasen när du frågar samma data. Mer information finns i avsnittet Datasvarstid för sekundär replik .

Tillgänglighetsgruppen för diagnostikrapporten 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 har tillståndet Inte synkroniserad .

När du granskar SQL Server felloggarna för dessa repliker kan du observera meddelanden som följande som indikerar 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 incheckningsredundanspartnern 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änglighetsgruppdatabasen är redundansklar just nu. 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 Felloggen för Microsoft SQL Server och Windows-programloggen. Repliken som rapporterar tidsgränsen försöker omedelbart återansluta och fortsätter att försöka var femte sekund.

Normalt identifieras tidsgränsen för anslutningen och rapporteras av endast 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 någon 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 inte den primära repliken någon timeout 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 inte betjänar speglingsslutpunktsanslutningen inom tillgänglighetsgruppsperiodenSESSION_TIMEOUT. Detta leder till att anslutningen överskrider tidsgränsen. Några av följande orsaker är:

• SQL Server har 100 procent processoranvändning. Det innebär att SQL Server eller något annat program driver CPU i sekunder i taget.

• SQL Server upplever 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, minnesproblem eller programproblem som påverkar dess förmåga att hantera anslutningen till speglingsslutpunkten.

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

I det här avsnittet beskrivs hur du analyserar SQL Server loggar för problem med program som förhindrar SQL Server från att underhålla anslutningen med partnerrepliken. De här tipsen kan hjälpa dig att identifiera rotorsaken till tidsgränsen 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änser för anslutning. Att använda de meddelanden som du hittar i SQL Server felloggen är ett bra sätt att göra detta. Var rapporteras tidsgränserna för anslutningen? Rapporteras de konsekvent på den primära eller sekundära repliken? När uppstod felen? Inträffade de under en viss vecka i månaden, veckodagen eller tiden på dagen? Motsvarar annat schemalagt underhåll eller batchbearbetning tiden då tidsgränserna för anslutningen observerades? Den här utvärderingen kan hjälpa dig att begränsa och korrelera tidsgränsen för anslutning för att identifiera rotorsaken.

Granska den AlwaysOn_health utökade händelsesessionen

Den AlwaysOn_health utökade händelsesessionen utökades så att den ucs_connection_setup inkluderade händelsen, som utlöses när en replik upprättar en anslutning till dess partnerreplik. Detta kan vara användbart när du felsöker problem med tidsgränser för anslutning.

Obs!

Den ucs_connection_setup utökade händelsen lades till i de senaste SQL Server kumulativa uppdateringarna. Du måste köra de senaste kumulativa uppdateringarna för att observera den här utökade händelsen.

Fråga Alltid om distribuerade hanteringsvyer (DMV:er)

Du kan fråga AlwaysOn DMV:er för 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 anslutningens timeout vid den tidpunkt då 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 varaktigt 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 den 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 AlwaysOn

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

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 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 konturrutan 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-givande händelser orsakar tidsgränser för anslutning

En av de vanligaste orsakerna till att en tillgänglighetsreplik inte kan hantera partnerreplikanslutningen är en icke-givande schemaläggare. Mer information om icke-givande schemalä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 om du vill söka efter icke-givande hä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. Därför behöver du inte schemalägga det här jobbet så att det körs var femte sekund, bara starta 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'
   

   Obs!

   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 noterar du tidsstämpeln för timeout-händelsen som visas i SQL Server felloggen. För replikerna i följande exempel SQL19AGN1 rapporterades tidsgränsen 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ör sp_server_diagnostics runt den rapporterade tiden, särskilt genom att granska TrackingNonYieldingScheduler 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 den SQL19AGN1 (kl. 07:24:31).

Obs!

Följande sp_server_diagnostics utdata sammanfogas för att visa både (tidsstämpeln create_time ) och query_processing TrackingNonYieldingScheduler resultaten.

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

Om du har verifierat från de tidigare diagnosstegen att en icke-givande händelse orsakade tidsgränsen för replikanslutningen:

1. Identifiera de arbetsbelastningar som körs i SQL Server när de icke-givande händelserna körs.

2. På samma sätt som tidsgränsen 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-givande händelsen upptäcktes.

4. Samla in viktiga prestandarä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 är nödvändigt öppnar du en SQL Server supportincident för ytterligare hjälp med att hitta rotorsaken till dessa icke-givande hä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 anslutningens tidsgräns.

Följande procedur startar en Windows-nätverksspårning netsh på replikerna där tidsgränsen för anslutningen rapporteras i SQL Server felloggarna. En schemalagd Händelseaktivitet i Windows utlöses när ett av SQL Server anslutningsfel registreras i programloggen. Den schemalagda aktiviteten kör ett kommando för att stoppa nätverksspårningen netsh så att viktiga nä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 har stoppats och registrerats kan du ta bort ONEVENT uppgifterna:

   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 Supportteamet för Microsoft SQL Server och anger spårningen tillsammans med andra begärda loggfiler för rotorsaksanalys.

Vad mer kan jag göra för att minska tidsgränsen 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);