Felsöka problem med automatisk redundans i SQL Server AlwaysOn-miljöer

Den här artikeln hjälper dig att lösa problem som uppstår under automatisk redundansväxling i Microsoft SQL Server.

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 2833707

Sammanfattning

SQL Server AlwaysOn-tillgänglighetsgrupper kan konfigureras för automatisk redundans. Om ett hälsoproblem identifieras på instansen av SQL Server som är värd för den primära repliken, kan den primära rollen överföras till den automatiska redundanspartnern (sekundär replik). Den sekundära repliken kan dock inte alltid övergå till den primära rollen. I vissa fall kan den endast överföras till RESOLVING rollen. I det här fallet har ingen replik den primära rollen om inte den primära repliken återgår till ett felfritt tillstånd. Dessutom är tillgänglighetsdatabaserna otillgängliga.

Den här artikeln innehåller några vanliga orsaker till misslyckad automatisk redundans och beskriver de steg som du kan vidta för att diagnostisera orsaken till dessa fel.

Symptom om en automatisk redundansväxling utlöses

När en automatisk redundansväxling utlöses på instansen av SQL Server som är värd för den primära repliken, övergår den sekundära repliken till RESOLVING rollen och sedan till den primära rollen. Även om processen lyckas loggas felposter i den SQL Server loggrapporten som liknar följande text:

The state of the local availability replica in availability group '\<Group name>' has changed from 'RESOLVING_NORMAL' to 'PRIMARY_PENDING'  
The state of the local availability replica in availability group '\<Group name>' has changed from 'PRIMARY_PENDING' to 'PRIMARY_NORMAL'

Symptom om en automatisk redundansväxling misslyckas

Om en automatisk redundanshändelse inte lyckas övergår inte den sekundära repliken till den primära rollen. Därför rapporterar tillgänglighetsrepliken att repliken är i ett RESOLVING tillstånd. Dessutom rapporterar tillgänglighetsdatabaserna att de är i ett NOT SYNCHRONIZING tillstånd och program kan inte komma åt dessa databaser.

I följande bild rapporterar SQL Server Management Studio till exempel att den sekundära repliken är i ett RESOLVING tillstånd eftersom den automatiska redundansväxlingen inte kunde överföra den sekundära repliken till den primära rollen.

I följande avsnitt beskrivs flera möjliga orsaker till varför automatisk redundans kanske inte lyckas och hur du diagnostiserar varje orsak.

Fall 1: Värdet "Maximalt antal fel i den angivna perioden" är slut

Tillgänglighetsgruppen har resursegenskaper för Windows-kluster, till exempel maximalt antal fel i egenskapen Angiven period . Den här egenskapen används för att undvika obegränsad förflyttning av en klustrad resurs när flera nodfel inträffar.

Om du vill undersöka och diagnostisera om detta är orsaken till misslyckad redundans granskar du Windows-klusterloggen (Cluster.log) och kontrollerar sedan egenskapen.

Steg 1: Granska data i Windows-klusterloggen (Cluster.log)

1. Använd Windows PowerShell för att generera Windows-klusterloggen på klusternoden som är värd för den primära repliken. Det gör du genom att köra följande cmdlet i ett upphöjt PowerShell-fönster på instansen av SQL Server som är värd för den primära repliken:

   Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
   

   

   [! ANTECKNINGAR]

   • Parametern -TimeSpan 15 i det här steget förutsätter att problemet som diagnostiserats inträffade under de senaste 15 minuterna.
   • Som standard skapas loggfilen i %WINDIR%\cluster\reports.

2. Öppna filen Cluster.log i Anteckningar för att granska Windows-klusterloggen.

3. I Anteckningar väljer du Redigera>sök och söker sedan efter strängen "failoverCount" i slutet av filen. I resultatet bör du hitta ett meddelande som liknar följande meddelande:

   Redundansväxlar inte gruppresursnamn<>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2

   

Steg 2: Kontrollera maximalt antal fel i egenskapen Angiven period

1. Starta Klusterhanteraren för växling vid fel.

2. I navigeringsfönstret väljer du Roller.

3. I fönstret Roller högerklickar du på den klustrade resursen och väljer sedan Egenskaper.

4. Välj fliken Redundans och välj Maximalt antal fel i värdet Angiven period .

   

   Obs!

   Standardbeteendet anger att om den klustrade resursen misslyckas tre gånger inom sex timmar ska den förbli i feltillstånd. För en tillgänglighetsgrupp innebär det att repliken lämnas i RESOLVING tillståndet .

Sammanfattning

När du har analyserat loggen upptäcker du att värdet för failoverCountpå 3 är större än värdet computedFailoverThresholdpå 2. Därför kan Windows-klustret inte slutföra redundansåtgärden för tillgänglighetsgruppresursen till redundanspartnern.

Lösning

Lös problemet genom att öka värdet Maximalt antal fel i den angivna perioden .

Fall 2: Otillräcklig NT-utfärdare\SYSTEMkontobehörigheter

Resurs-DLL:et SQL Server Database Engine ansluter till instansen av SQL Server som är värd för den primära repliken med hjälp av ODBC för att övervaka hälsotillståndet. Inloggningsuppgifterna som används för den här anslutningen är det lokala SQL Server NT AUTHORITY\SYSTEM inloggningskontot. Som standard beviljas det här lokala inloggningskontot följande behörigheter:

• Ändra alla tillgänglighetsgrupper
• Anslut SQL
• Visa servertillstånd

NT AUTHORITY\SYSTEM Om inloggningskontot saknar någon av dessa behörigheter för den automatiska redundanspartnern (den sekundära repliken) kan SQL Server inte starta hälsoidentifiering när en automatisk redundansväxling sker. Därför kan den sekundära repliken inte övergå till den primära rollen. Om du vill undersöka och diagnostisera om detta är orsaken läser du Windows-klusterloggen. Gör så här:

1. Använd Windows PowerShell för att generera Windows-klusterloggen på klusternoden. Det gör du genom att köra följande cmdlet i ett upphöjt PowerShell-fönster på instansen av SQL Server som är värd för den sekundära repliken som inte övergick till den primära rollen:

   Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
   

   

2. Öppna filen Cluster.log i Anteckningar för att granska Windows-klusterloggen.

3. Hitta felpost som liknar följande text:

   Det gick inte att köra diagnostikkommandot. Användaren har inte behörighet att utföra den här åtgärden.

   

Sammanfattning

Den Cluster.log filen rapporterar att det finns ett behörighetsproblem när SQL Server kör diagnostikkommandot. I det här exemplet orsakades felet av att behörigheten Visa servertillstånd togs bort från NT AUTHORITY\SYSTEM inloggningskontot på instansen av SQL Server som är värd för den sekundära repliken av ett automatiskt redundanspar.

Lösning

Lös problemet genom att bevilja tillräcklig behörighet till NT AUTHORITY\SYSTEM inloggningskontot för hälsoidentifiering av resurs-DLL för SQL Server-databasmotorn.

Fall 3: Tillgänglighetsdatabaserna är inte i ett SYNKRONISERAT tillstånd

Om du vill redundansväxla automatiskt måste alla tillgänglighetsdatabaser som definieras i tillgänglighetsgruppen vara i ett SYNCHRONIZED tillstånd mellan den primära repliken och den sekundära repliken. När en automatisk redundansväxling sker måste det här synkroniseringsvillkoret uppfyllas för att säkerställa att inga data går förlorade. Om en tillgänglighetsdatabas i tillgänglighetsgruppen är i synkroniserings- eller NOT SYNCHRONIZED tillståndsläge, kommer automatisk redundans därför inte att överföra den sekundära repliken till den primära rollen.

Mer information om de nödvändiga villkoren för automatisk redundans finns i Villkor som krävs för automatisk redundans och repliker med synkron incheckning stöder två inställningsavsnitt i redundanslägen och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

Om du vill undersöka och diagnostisera om det här är orsaken till misslyckad redundansväxling läser du SQL Server felloggen. Du bör hitta en felpost som liknar följande text:

En eller flera databaser är inte synkroniserade eller har inte anslutit till tillgänglighetsgruppen.

Följ dessa steg för att kontrollera om tillgänglighetsdatabaserna var i SYNCHRONIZED tillståndet:

1. Anslut till den sekundära repliken.

2. Kör följande SQL-skript för att kontrollera is_failover_ready värdet för alla tillgänglighetsdatabaser i tillgänglighetsgruppen som inte redundansväxlar.

   Obs!

   Ett värde på noll för någon av tillgänglighetsdatabaserna kan förhindra automatisk redundans. Det här värdet anger att tillgänglighetsdatabasen inte SYNCHRONIZEDvar .

   SELECT database_name, is_failover_ready FROM sys.dm_hadr_database_replica_cluster_states WHERE replica_id IN (SELECT replica_id FROM sys.dm_hadr_availability_replica_states)
   

   

Sammanfattning

En lyckad automatisk redundansväxling av tillgänglighetsgruppen kräver att alla tillgänglighetsdatabaser är i SYNCHRONIZED tillståndet . Mer information om tillgänglighetslägen finns i Tillgänglighetslägen i AlwaysOn-tillgänglighetsgrupper.

Fall 4: Konfigurationen "Force Protocol Encryption" har valts för klientprotokollen på den sekundära repliken (primär målreplik) även om repliken inte har konfigurerats för kryptering

När den primära servern under redundansväxlingen upptäcker ett hälsoproblem försöker kluster-DLL:n på redundanspartnern (sekundär replik) ansluta till den lokala repliken för att initiera hälsoövervakning. Detta är en del av övergången till den primära rollen. Om den sekundära repliken inte har konfigurerats för kryptering, men inställningen Force Protocol Encryption oavsiktligt anges i klientkonfigurationen, misslyckas anslutningen och redundansväxlingen kan inte utföras.

Så här söker du efter den här konfigurationen:

1. Starta Konfigurationshanteraren för SQL Server.
2. Högerklicka på SQL Native Client 11.0-konfigurationen i den vänstra rutan och välj sedan Egenskaper.
3. I dialogrutan markerar du inställningen Tvinga protokollkryptering . Om värdet är inställt på Ja ändrar du värdet till Nej.
4. Testa redundansväxlingen igen.

Sammanfattning

SQL Server AlwaysOn-hälsoövervakning använder en lokal ODBC-anslutning för att övervaka SQL Server hälsa. Force Protocol Encryption ska endast aktiveras i avsnittet Klientkonfiguration i Konfigurationshanteraren för SQL Server om SQL Server har konfigurerats för att tvinga krypteringar i Konfigurationshanteraren för SQL Server i SQL Server avsnittet Nätverkskonfiguration. Mer information finns i Aktivera krypterade anslutningar till databasmotorn.

Fall 5: Prestandaproblem på sekundär replik eller nod gör att AlwaysOn-hälsokontroller misslyckas

Innan du redväxlar från den primära repliken till den sekundära repliken ansluter SQL Server Database Engine-resursens DLL till den sekundära repliken för att fastställa replikens hälsa. Om den här anslutningen misslyckas på grund av prestandaproblem på den sekundära repliken sker inte automatisk redundans.

Om du vill undersöka och diagnostisera om det här är orsaken följer du dessa steg:

1. Granska klusterloggen på den sekundära repliken för att söka efter felmeddelandet "Det går inte att slutföra inloggningsprocessen på grund av fördröjning i öppnandet av serveranslutningen".

   0000110c.00002bcc::2020/08/06-01:17:54.943 INFO  [RCM] move of group AOCProd01AG from CO2ICMV3SQL09(1) to CO2ICMV3SQL10(2) of type MoveType::Manual is about to succeed, failoverCount=3, lastFailoverTime=2020/08/05-02:08:54.524 targeted=true 
   00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]Unable to complete login process due to delay in opening server connection (0) 
   00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Could not connect to SQL Server (rc -1) 
   00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] SQLDisconnect returns following information 
   00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08003] [Microsoft][ODBC Driver Manager] Connection not open (0) 
   00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Failed to connect to SQL Server 
   00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RHS] Online for resource AOCProd01AG failed. 
   

   Den här situationen kan inträffa om redundansväxlingen görs till en SQL Server sekundär replik som har en upptagen befintlig arbetsbelastning. Detta kan fördröja SQL Server svar på begäran om HADR-hälsoanslutning och förhindra ett lyckat redundansförsök.

2. För att avgöra om det finns tryck på systemschemaläggare använder du SQL Server Management Studio för att köra följande skript på den sekundära repliken:

   USE MASTER 
   GO  
   WHILE 1=1 
   BEGIN 
   PRINT convert(varchar(20), getdate(),120) 
   DECLARE @max INT; 
   SELECT @max = max_workers_count 
   FROM sys.dm_os_sys_info; 
   SELECT GETDATE() AS 'CurrentDate',  
          @max AS 'TotalThreads',  
          SUM(active_Workers_count) AS 'CurrentThreads',  
          @max - SUM(active_Workers_count) AS 'AvailableThreads',  
          SUM(runnable_tasks_count) AS 'WorkersWaitingForCpu',  
          SUM(work_queue_count) AS 'RequestWaitingForThreads' 
          --SUM(current_workers_count) AS 'AssociatedWorkers' 
   FROM sys.dm_os_Schedulers 
   WHERE STATUS = 'VISIBLE ONLINE'; 
   wait for delay '0:0:15' 
   END
   

   Följande är exempelutdata från föregående fråga:

   CurrentDate	TotalThreads	CurrentThreads	AvailableThreads	ArbetareWaitingForCpu	RequestWaitingForThreads
   2020-10-06 01:27:01.337	1216	361	855	33	0
   2020-10-06 01:27:08.340	1216	1412	-196	22	76
   2020-10-06 01:27:15.340	1216	1304	-88	2	161
   2020-10-06 01:27:22.340	1216	1242	-26	21	185
   2020-10-06 01:27:29.343	1216	1346	-130	19	476
   2020-10-06 01:27:36.350	1216	1350	-134	9	630
   2020-10-06 01:27:43.353	1216	1346	-130	13	539
   2020-10-06 01:27:50.360	1216	1378	-162	5	328
   2020-10-06 01:27:57.360	1216	197	1019	0	0

   Höga värden rapporteras för WorkersWaitingForCpu och RequestWaitingForThreads indikerar att schemaläggningskonkurration pågår och att SQL Server inte kan betjäna den aktuella arbetsbelastningen i tid.

Lösning

Om det här problemet uppstår kan du balansera om arbetsbelastningen på den sekundära repliken eller överväga att öka bearbetningskraften (lägg till processorer) på datorerna som kör dessa arbetsbelastningar.

Felsöka andra redundansväxlingshändelser

Om du vill övervaka hälsotillståndet för den nya primära repliken under redundansväxlingen måste du lokalt ansluta AlwaysOn-hälsoövervakning till den SQL Server instans som övergår till den primära rollen.

Förutom de vanligaste orsakerna som beskrivs i den här artikeln finns det många andra orsaker till att det här anslutningsförsöket kan misslyckas. Om du vill undersöka ett redundansförsök ytterligare granskar du klusterloggen på redundanspartnern (repliken som du inte kunde redundansväxla till):

1. Använd Windows PowerShell för att generera Windows-klusterloggen på klusternoden. Det gör du genom att köra följande cmdlet i ett upphöjt PowerShell-fönster på instansen av SQL Server som är värd för den sekundära repliken som inte övergick till den primära rollen. En klusterlogg genereras för de senaste 60 minuternas aktivitet.

   Get-ClusterLog -Node <SQLServerNodeName> -TimeSpan 60
   

2. Om du vill granska Windows-klusterloggen öppnar du filen Cluster.log i Anteckningar.

3. Sök efter strängen "Anslut till SQL Server" som infaller under den misslyckade redundanshändelsen.

4. Granska efterföljande inloggningsmeddelanden med hjälp av tråd-ID :t (se följande skärmbild) för att korrelera de händelser som är relaterade till inloggningshändelsen. I följande exempel visas en sökning efter "Anslut till SQL Server". Den visar också hur du använder tråd-ID :t (vänster sida) för att hitta den andra diagnostiken som beskriver varför anslutningsförsöket misslyckades.

   

I följande exempel visas anslutningsfel till den nya primära repliken.

Exempeluppsättning 1

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: No client protocols are enabled and no protocol was specified in the connection
string [xFFFFFFFF]. (268435455)

Lösning

Starta Konfigurationshanteraren för SQL Server och kontrollera sedan att delat minne eller TCP/IP är aktiverat under Klientprotokoll för SQL Native Client-konfigurationen.

Exempeluppsättning 2

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: Server doesn't support requested protocol [xFFFFFFFF]. (268435455)

Lösning

Starta Konfigurationshanteraren för SQL Server och kontrollera sedan att delat minne eller TCP/IP är aktiverat under Klientprotokoll för SQL Native Client-konfigurationen.

Exempeluppsättning 3

000010b8.00001764::2020/12/02-16:52:49.808 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot alter the availability
group 'ag', because it does not exist or you do not have permission. (15151)
000010b8.00000fd0::2020/12/02-17:01:14.821 ERR [RES] SQL Server Availability Group: [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]The user does not have permission to perform this action. (297)
000010b8.00001838::2020/12/02-17:10:04.427 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user
'SQLREPRO\NODE2$'. Reason: The account is disabled. (18470)

Lösning

Granska fall 2: Otillräckliga behörigheter för NT-utfärdare\SYSTEM-konto.