Behandeln von Problemen mit automatischem Failover in SQL Server Always On Umgebungen

Dieser Artikel hilft Ihnen bei der Behebung von Problemen, die beim automatischen Failover in Microsoft SQL Server auftreten.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 2833707

Zusammenfassung

SQL Server Always On Verfügbarkeitsgruppen können für automatisches Failover konfiguriert werden. Wenn auf der instance von SQL Server, die das primäre Replikat hostet, ein Integritätsproblem erkannt wird, kann die primäre Rolle auf den Partner für automatisches Failover (sekundäres Replikat) übertragen werden. Das sekundäre Replikat kann jedoch nicht immer auf die primäre Rolle umgestellt werden. In einigen Fällen kann es nur auf die RESOLVING Rolle umgestellt werden. In diesem Fall hat kein Replikat die primäre Rolle, es sei denn, das primäre Replikat kehrt in einen fehlerfreien Zustand zurück. Darüber hinaus kann nicht auf die Verfügbarkeitsdatenbanken zugegriffen werden.

In diesem Artikel werden einige häufige Ursachen für erfolgloses automatisches Failover aufgeführt, und es werden die Schritte erläutert, die Sie ausführen können, um die Ursache dieser Fehler zu diagnostizieren.

Symptome, wenn ein automatisches Failover erfolgreich ausgelöst wird

Wenn ein automatisches Failover auf der instance von SQL Server ausgelöst wird, die das primäre Replikat hostet, wechselt das sekundäre Replikat in die RESOLVING Rolle und dann in die primäre Rolle. Obwohl der Prozess erfolgreich ist, werden Fehlereinträge im SQL Server Protokollbericht protokolliert, die dem folgenden Text ähneln:

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'

Hinweis

Das sekundäre Replikat wechselt erfolgreich von einem RESOLVING_NORMAL Zustand in einen PRIMARY_NORMAL Zustand.

Symptome, wenn ein automatisches Failover nicht erfolgreich ist

Wenn ein automatisches Failoverereignis nicht erfolgreich ist, wechselt das sekundäre Replikat nicht erfolgreich in die primäre Rolle. Daher meldet das Verfügbarkeitsreplikat, dass sich dieses Replikat in einem RESOLVING Zustand befindet. Darüber hinaus melden die Verfügbarkeitsdatenbanken, dass sie sich in einem NOT SYNCHRONIZING Zustand befinden, und Anwendungen können nicht auf diese Datenbanken zugreifen.

In der folgenden Abbildung meldet SQL Server Management Studio beispielsweise, dass sich das sekundäre Replikat in einem RESOLVING Zustand befindet, da der automatische Failoverprozess das sekundäre Replikat nicht in die primäre Rolle übergehen konnte.

In den folgenden Abschnitten werden mehrere mögliche Gründe erläutert, warum das automatische Failover möglicherweise nicht erfolgreich ist, und wie die einzelnen Ursachen diagnostiziert werden.

Fall 1: Der Wert "Maximale Fehler im angegebenen Zeitraum" ist erschöpft.

Die Verfügbarkeitsgruppe verfügt über Eigenschaften von Windows-Clusterressourcen, z. B . maximale Fehler in der Eigenschaft "Angegebener Zeitraum ". Diese Eigenschaft wird verwendet, um die unbestimmte Verschiebung einer gruppierten Ressource zu vermeiden, wenn mehrere Knotenfehler auftreten.

Um zu untersuchen und zu diagnostizieren, ob dies die Ursache für ein nicht erfolgreiches Failover ist, überprüfen Sie das Windows-Clusterprotokoll (Cluster.log), und überprüfen Sie dann die -Eigenschaft.

Schritt 1: Überprüfen der Daten im Windows-Clusterprotokoll (Cluster.log)

1. Verwenden Sie Windows PowerShell, um das Windows-Clusterprotokoll auf dem Clusterknoten zu generieren, auf dem das primäre Replikat gehostet wird. Führen Sie hierzu das folgende Cmdlet in einem PowerShell-Fenster mit erhöhten Rechten auf der instance von SQL Server aus, die das primäre Replikat hostet:

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

   

   [! HINWEISE]

   • Der -TimeSpan 15 Parameter in diesem Schritt geht davon aus, dass das diagnostizierte Problem in den letzten 15 Minuten aufgetreten ist.
   • Standardmäßig wird die Protokolldatei in %WINDIR%\cluster\reports erstellt.

2. Öffnen Sie die Cluster.log-Datei im Editor, um das Windows-Clusterprotokoll zu überprüfen.

3. Wählen Sie im EditorDie Suchebearbeiten> aus, und suchen Sie dann am Ende der Datei nach der Zeichenfolge "failoverCount". In den Ergebnissen sollte eine Meldung angezeigt werden, die der folgenden Meldung ähnelt:

   Kein Failover der Gruppe <Ressourcenname>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2

   

Schritt 2: Überprüfen der maximalen Fehler in der Eigenschaft "Angegebener Zeitraum"

1. Starten Sie den Failovercluster-Manager.

2. Wählen Sie im Navigationsbereich Rollen aus.

3. Klicken Sie im Bereich Rollen mit der rechten Maustaste auf die gruppierte Ressource, und wählen Sie dann Eigenschaften aus.

4. Wählen Sie die Registerkarte Failover aus, und wählen Sie im Wert Für den angegebenen Zeitraum die Option Maximale Fehler aus.

   

   Hinweis

   Das Standardverhalten gibt an, dass, wenn die gruppierte Ressource innerhalb von sechs Stunden dreimal ausfällt, sie im Fehlerzustand verbleiben soll. Für eine Verfügbarkeitsgruppe bedeutet dies, dass das Replikat im RESOLVING Zustand verbleibt.

Schlussbemerkung

Nachdem Sie das Protokoll analysiert haben, stellen Sie fest, dass der failoverCount-Wert von 3 größer als der computedFailoverThreshold-Wert von 2 ist. Daher kann der Windows-Cluster den Failovervorgang der Verfügbarkeitsgruppenressource zum Failoverpartner nicht abschließen.

Lösung

Um dieses Problem zu beheben, erhöhen Sie die Maximale Anzahl von Fehlern im Wert für den angegebenen Zeitraum .

Hinweis

Wenn Sie diesen Wert erhöhen, wird das Problem möglicherweise nicht behoben. Möglicherweise liegt ein kritischeres Problem vor, das dazu führt, dass die Verfügbarkeitsgruppe innerhalb eines kurzen Zeitraums mehrmals fehlschlägt. Standardmäßig beträgt dieser Zeitraum 15 Minuten. Das Erhöhen dieses Werts kann einfach dazu führen, dass die Verfügbarkeitsgruppe mehr Mal fehlschlägt und in einem fehlerhaften Zustand verbleibt. Es wird empfohlen, die aggressive Problembehandlung zu verwenden, um zu bestimmen, warum das automatische Failover weiterhin auftritt.

Fall 2: Unzureichende NT Authority\SYSTEM-Kontoberechtigungen

Die SQL Server-Datenbank-Engine-Ressourcen-DLL stellt eine Verbindung mit dem instance von SQL Server her, das das primäre Replikat hostet, indem odbc zur Überwachung der Integrität verwendet wird. Die Anmeldeinformationen, die für diese Verbindung verwendet werden, sind das lokale SQL Server NT AUTHORITY\SYSTEM Anmeldekonto. Standardmäßig werden diesem lokalen Anmeldekonto die folgenden Berechtigungen erteilt:

• Ändern einer beliebigen Verfügbarkeitsgruppe
• SQL verbinden
• Anzeigen des Serverstatus

Wenn dem NT AUTHORITY\SYSTEM Anmeldekonto eine dieser Berechtigungen für den Partner für automatisches Failover (das sekundäre Replikat) fehlt, kann SQL Server die Integritätserkennung nicht starten, wenn ein automatisches Failover auftritt. Daher kann das sekundäre Replikat nicht zur primären Rolle wechseln. Überprüfen Sie das Windows-Clusterprotokoll, um zu untersuchen und zu diagnostizieren, ob dies die Ursache ist. Gehen Sie dazu wie folgt vor:

1. Verwenden Sie Windows PowerShell, um das Windows-Clusterprotokoll auf dem Clusterknoten zu generieren. Führen Sie dazu das folgende Cmdlet in einem PowerShell-Fenster mit erhöhten Rechten auf der instance von SQL Server aus, die das sekundäre Replikat hostet, das nicht in die primäre Rolle überstieg:

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

   

2. Öffnen Sie die Cluster.log-Datei im Editor, um das Windows-Clusterprotokoll zu überprüfen.

3. Suchen Sie nach einem Fehlereintrag, der dem folgenden Text ähnelt:

   Fehler beim Ausführen Diagnose Befehls. Der Benutzer verfügt nicht über die Berechtigung zum Ausführen dieser Aktion.

   

Schlussbemerkung

Die datei Cluster.log meldet, dass ein Berechtigungsproblem vorliegt, wenn SQL Server den Befehl Diagnose ausführt. In diesem Beispiel wurde der Fehler dadurch verursacht, dass die Berechtigung Serverstatus anzeigen aus dem NT AUTHORITY\SYSTEM Anmeldekonto auf der instance von SQL Server entfernt wurde, die das sekundäre Replikat eines automatischen Failoverpaars hostet.

Lösung

Um dieses Problem zu beheben, gewähren Sie dem NT AUTHORITY\SYSTEM Anmeldekonto ausreichende Berechtigungen für die Integritätserkennung der SQL Server-Datenbank-Engine-Ressourcen-DLL.

Fall 3: Die Verfügbarkeitsdatenbanken befinden sich nicht im Status SYNCHRONIZED

Für ein automatisches Failover müssen sich alle Verfügbarkeitsdatenbanken, die in der Verfügbarkeitsgruppe definiert sind, in einem SYNCHRONIZED Zustand zwischen dem primären Replikat und dem sekundären Replikat befinden. Wenn ein automatisches Failover auftritt, muss diese Synchronisierungsbedingung erfüllt sein, um sicherzustellen, dass keine Datenverluste auftreten. Wenn sich also eine Verfügbarkeitsdatenbank in der Verfügbarkeitsgruppe im Synchronisierungs- oder NOT SYNCHRONIZED Zustand befindet, wird das sekundäre Replikat beim automatischen Failover nicht erfolgreich in die primäre Rolle übergehen.

Weitere Informationen zu den erforderlichen Bedingungen für ein automatisches Failover finden Sie unter Bedingungen, die für ein automatisches Failover erforderlich sind, und die Replikate mit synchronem Commit unterstützen zwei Einstellungen unter Failover und Failovermodi (Always On Verfügbarkeitsgruppen).

Um zu untersuchen und zu diagnostizieren, ob dies die Ursache für ein nicht erfolgreiches Failover ist, überprüfen Sie das SQL Server Fehlerprotokoll. Sie sollten einen Fehlereintrag finden, der dem folgenden Text ähnelt:

Mindestens eine Datenbank wird nicht synchronisiert oder ist der Verfügbarkeitsgruppe nicht beigetreten.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob sich die Verfügbarkeitsdatenbanken im SYNCHRONIZED Zustand befanden:

1. Stellen Sie eine Verbindung mit dem sekundären Replikat her.

2. Führen Sie das folgende SQL-Skript aus, um den is_failover_ready Wert für alle Verfügbarkeitsdatenbanken in der Verfügbarkeitsgruppe zu überprüfen, für die kein Failover durchgeführt wurde.

   Hinweis

   Der Wert 0 (null) für eine der Verfügbarkeitsdatenbanken kann ein automatisches Failover verhindern. Dieser Wert gibt an, dass die Verfügbarkeitsdatenbank nicht SYNCHRONIZEDwar.

   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)
   

   

Schlussbemerkung

Ein erfolgreiches automatisches Failover der Verfügbarkeitsgruppe erfordert, dass sich alle Verfügbarkeitsdatenbanken im Zustand befinden SYNCHRONIZED . Weitere Informationen zu Verfügbarkeitsmodi finden Sie unter Verfügbarkeitsmodi in Always On Verfügbarkeitsgruppen.

Fall 4: Die Konfiguration "Protokollverschlüsselung erzwingen" ist für die Clientprotokolle auf dem sekundären Replikat (primäres Ziel) ausgewählt, obwohl das Replikat nicht für die Verschlüsselung konfiguriert ist.

Wenn der primäre Server während eines Failovers ein Integritätsproblem erkennt, versucht die Cluster-DLL auf dem Failoverpartner (sekundäres Replikat), eine Verbindung mit dem lokalen Replikat herzustellen, um die Integritätsüberwachung zu initiieren. Dies ist Teil des Übergangs zur primären Rolle. Wenn das sekundäre Replikat nicht für die Verschlüsselung konfiguriert ist, aber die Einstellung Protokollverschlüsselung erzwingen in der Clientkonfiguration versehentlich festgelegt ist, schlägt die Verbindung fehl, und das Failover kann nicht erfolgen.

So überprüfen Sie diese Konfiguration:

1. Starten Sie den SQL Server-Konfigurations-Manager.
2. Klicken Sie im linken Bereich mit der rechten Maustaste auf die SQL Native Client 11.0-Konfiguration, und wählen Sie dann Eigenschaften aus.
3. Aktivieren Sie im Dialogfeld die Einstellung Protokollverschlüsselung erzwingen . Wenn sie auf Ja festgelegt ist, ändern Sie den Wert in Nein.
4. Testen Sie das Failover erneut.

Schlussbemerkung

SQL Server Always On Integritätsüberwachung verwendet eine lokale ODBC-Verbindung, um SQL Server Integrität zu überwachen. Protokollverschlüsselung erzwingen sollte nur dann im Abschnitt Clientkonfiguration von SQL Server-Konfigurations-Manager aktiviert werden, wenn SQL Server selbst für Erzwingen von Verschlüsselungen in SQL Server-Konfigurations-Manager im SQL Server Abschnitt "Netzwerkkonfiguration". Weitere Informationen finden Sie unter Aktivieren verschlüsselter Verbindungen mit der Datenbank-Engine.

Fall 5: Leistungsprobleme auf sekundären Replikaten oder Knoten führen dazu, dass Always On Integritätsprüfungen fehlschlagen

Vor dem Failover vom primären Replikat zum sekundären Replikat stellt SQL Server Datenbank-Engine-Ressourcen-DLL eine Verbindung mit dem sekundären Replikat her, um die Integrität des Replikats zu ermitteln. Wenn diese Verbindung aufgrund von Leistungsproblemen auf dem sekundären Replikat fehlschlägt, erfolgt kein automatisches Failover.

Führen Sie die folgenden Schritte aus, um zu untersuchen und zu diagnostizieren, ob dies die Ursache ist:

1. Überprüfen Sie das Clusterprotokoll auf dem sekundären Replikat, um die Fehlermeldung "Anmeldevorgang kann aufgrund einer Verzögerung beim Öffnen der Serververbindung nicht abgeschlossen werden" zu überprüfen.

   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. 
   

   Diese Situation kann auftreten, wenn das Failover auf ein SQL Server sekundäres Replikat erfolgt, das bereits ausgelastet ist. Dies könnte die Antwort SQL Server auf den Verbindungsversuch der HADR-Integrität verzögern und einen erfolgreichen Failoverversuch verhindern.

2. Verwenden Sie SQL Server Management Studio, um das folgende Skript auf dem sekundären Replikat auszuführen, um zu ermitteln, ob die Systemplaner unter Druck stehen:

   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
   

   Es folgt eine Beispielausgabe der vorherigen Abfrage:

   CurrentDate	TotalThreads	CurrentThreads	AvailableThreads	WorkersWaitingForCpu	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

   Hohe Werte, die für WorkersWaitingForCpu und RequestWaitingForThreads gemeldet werden, geben an, dass Planungskonflikte auftreten und dass SQL Server die aktuelle Workload nicht rechtzeitig warten können.

Lösung

Wenn dieses Problem auftritt, müssen Sie die Workload auf dem sekundären Replikat neu ausgleichen oder die Verarbeitungsleistung auf den Computern, auf denen diese Workloads ausgeführt werden, erhöhen (Prozessoren hinzufügen).

Problembehandlung bei anderen failoverfehlern Ereignissen

Um die Integrität des neuen primären Replikats während des Failovers zu überwachen, müssen Sie die AlwaysOn-Integritätsüberwachung lokal mit dem SQL Server instance verbinden, der zur primären Rolle übergehen wird.

Zusätzlich zu den häufigeren Gründen, die in diesem Artikel erläutert werden, gibt es viele weitere Gründe, warum dieser Verbindungsversuch fehlschlagen kann. Um einen fehlgeschlagenen Failoverversuch weiter zu untersuchen, überprüfen Sie das Clusterprotokoll auf dem Failoverpartner (das Replikat, auf das Sie kein Failover ausführen konnten):

1. Verwenden Sie Windows PowerShell, um das Windows-Clusterprotokoll auf dem Clusterknoten zu generieren. Führen Sie hierzu das folgende Cmdlet in einem PowerShell-Fenster mit erhöhten Rechten auf der instance von SQL Server aus, die das sekundäre Replikat hostet, das nicht in die primäre Rolle überstieg. Ein Clusterprotokoll wird für die letzten 60 Minuten der Aktivität generiert.

   Get-ClusterLog -Node <SQLServerNodeName> -TimeSpan 60
   

2. Öffnen Sie zum Überprüfen des Windows-Clusterprotokolls die datei Cluster.log im Editor.

3. Suchen Sie nach der Zeichenfolge "Verbindung mit SQL Server herstellen", die während des nicht erfolgreichen Failoverereignisses fällt.

4. Überprüfen Sie die nachfolgenden Anmeldemeldungen mithilfe der Thread-ID (siehe folgenden Screenshot), um die Ereignisse zu korrelieren, die sich auf das Anmeldeereignis beziehen. Das folgende Beispiel zeigt eine Suche nach "Verbindung mit SQL Server herstellen". Außerdem wird gezeigt, wie die Thread-ID (links) verwendet wird, um die anderen Diagnose zu finden, die beschreiben, warum der Verbindungsversuch fehlgeschlagen ist.

   

Die folgenden Beispiele zeigen Verbindungsfehler mit dem neuen primären Replikat.

Beispielsatz 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ösung

Starten Sie SQL Server-Konfigurations-Manager, und überprüfen Sie dann, ob freigegebener Arbeitsspeicher oder TCP/IP unter Clientprotokolle für die SQL Native Client-Konfiguration aktiviert ist.

Beispielsatz 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ösung

Starten Sie SQL Server-Konfigurations-Manager, und überprüfen Sie dann, ob freigegebener Arbeitsspeicher oder TCP/IP unter Clientprotokolle für die SQL Native Client-Konfiguration aktiviert ist.

Beispielsatz 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ösung

Lesen Sie Fall 2: Unzureichende NT Authority\SYSTEM-Kontoberechtigungen.