WSFC-Notfallwiederherstellung durch erzwungenes Quorum (SQL Server)

Gilt für:SQL Server

Quorumfehler werden normalerweise durch eine systemische Katastrophe, einen persistenten Kommunikationsfehler oder eine fehlerhafte Konfiguration, die mehrere Knoten im WSFC-Cluster betreffen, verursacht. Zur Beseitigung eines Quorumfehlers ist ein manueller Eingriff erforderlich.

Voraussetzungen

Beim Verfahren zum Erzwingen eines Quorums wird davon ausgegangen, dass vor dem Quorumausfall ein intaktes Quorum vorhanden war.

Warnung

Der Benutzer sollte mit den Begriffen und Wechselwirkungen von Windows Server Failover Clustering, WSFC-Quorummodellen, SQL Serverund der spezifischen Bereitstellungskonfiguration der Umgebung vertraut sein.

Weitere Informationen finden Sie unter: Windows Server Failover Clustering (WSFC) mit SQL Server, WSFC-Quorummodi und Abstimmungskonfiguration (SQL Server).

Sicherheit

Der Benutzer muss einem Domänenkonto entsprechen, das Mitglied der lokalen Administratorgruppe an jedem Knoten des WSFC-Clusters ist.

WSFC-Notfallwiederherstellung durch das Verfahren zum Erzwingen eines Quorums

Vergessen Sie nicht, dass bei einem Quorumfehler alle gruppierten Dienste, SQL Server-Instanzen und Always On-Verfügbarkeitsgruppenim WSFC-Cluster offline geschaltet werden, da der Cluster in der aktuellen Konfiguration keine Fehlertoleranz auf Knotenebene gewährleisten kann. Ein Quorumfehler bedeutet, dass die funktionsfähigen abstimmungsberechtigten Knoten im WSFC-Cluster die Anforderungen des Quorummodells nicht mehr erfüllen. Einige Knoten sind möglicherweise völlig ausgefallen, und andere haben den WSFC-Dienst möglicherweise nur heruntergefahren und sind, abgesehen vom Verlust der Fähigkeit, mit einem Quorum zu kommunizieren, möglicherweise fehlerfrei.

Um den WSFC-Cluster wieder online zu schalten, müssen Sie die Ursache für den Quorumfehler in der vorhandenen Konfiguration beheben, die betroffenen Datenbanken nach Bedarf wiederherstellen und die übrigen Knoten im WSFC-Cluster neu konfigurieren, um die verbleibende Clustertopologie widerzuspiegeln.

Sie können die erzwungene Quorumprozedur für einen WSFC-Clusterknoten verwenden, um die Sicherheitskontrollen zu überschreiben, die den Cluster offline geschaltet haben. Damit wird der Cluster angewiesen, die Quorumabstimmungsprüfungen auszusetzen, und Sie können die WSFC-Clusterressourcen und SQL Server auf einem beliebigen Knoten im Cluster wieder online bringen.

Dieser Typ von Notfallwiederherstellungsprozess sollte die folgenden Schritte umfassen:

Wiederherstellung nach einem Quorumfehler:

  1. Bestimmen Sie den Fehlerumfang. Identifizieren Sie, welche Verfügbarkeitsgruppen oder SQL Server-Instanzen nicht mehr reagieren, welche Clusterknoten online sind und zur Verwendung nach der Katastrophe verfügbar sind, und untersuchen Sie die Windows-Ereignisprotokolle und die SQL Server-Systemprotokolle. Wo praktikabel, sollten Sie forensische Daten und Systemprotokolle für spätere Analysen beibehalten.

    Tipp

    Auf einer reagierenden Instanz von SQL Serverkönnen Sie Informationen zum Zustand von Verfügbarkeitsgruppen, die auf der lokalen Serverinstanz ein Verfügbarkeitsreplikat besitzen, abrufen, indem Sie die dynamische Verwaltungssicht (DMV, Dynamic Management View) sys.dm_hadr_availability_group_states abfragen.

  2. Starten Sie den WSFC-Cluster mit erzwungenem Quorum auf einem einzelnen Knoten. Identifizieren Sie einen Knoten mit möglichst wenigen Komponentenfehlern, sofern nicht der WSFC-Clusterdienst heruntergefahren wurde. Überprüfen Sie, ob dieser Knoten mit den meisten anderen Knoten kommunizieren kann.

    Erzwingen Sie auf diesem Knoten manuell, dass der Cluster mithilfe des Verfahrens für erzwungenes Quorum online geht. Um potenzielle Datenverluste zu minimieren, wählen Sie einen Knoten aus, der zuletzt ein primäres Replikat der Verfügbarkeitsgruppe gehostet hat.

    Weitere Informationen finden Sie unter: Erzwingen Sie den Start eines WSFC-Clusters ohne Quorum

    Hinweis

    Die erzwungene Quorumeinstellung wirkt clusterweit, indem sie Quorumprüfungen außer Kraft setzt, bis der logische WSFC-Cluster eine Stimmenmehrheit erreicht und automatisch in den regulären Quorumbetrieb übergeht.

  3. Starten Sie den WSFC-Dienst auf jedem ansonsten fehlerfreien Knoten normal, jeweils nacheinander. Sie müssen die erzwungene Quorumoption nicht angeben, wenn Sie den Clusterdienst auf den anderen Knoten starten.

    Sobald der WSFC-Dienst auf den einzelnen Knoten wieder online ist, verhandelt er mit den anderen fehlerfreien Knoten, um den neuen Clusterkonfigurationszustand zu synchronisieren. Denken Sie daran, jeweils nur einen Knoten gleichzeitig zu bearbeiten, um potenzielle Race Conditions beim Ermitteln des zuletzt bekannten Zustands des Clusters zu vermeiden.

    Warnung

    Stellen Sie sicher, dass jeder Knoten, den Sie starten, mit den anderen neu online geschalteten Knoten kommunizieren kann. Erwägen Sie, den WSFC-Dienst bei den anderen Knoten zu deaktivieren. Andernfalls laufen Sie Gefahr, mehr als einen Quorumknotensatz zu erstellen; d. h. ein Split-Brain-Szenario. Wenn Ihre Ermittlungsergebnisse in Schritt 1 richtig waren, sollte dieser Fall nicht eintreten.

  4. Übernehmen der neuen Quorummodus- und Knotenabstimmungskonfiguration. Wenn durch das Erzwingen des Quorums alle Knoten im Cluster erfolgreich neu gestartet wurden und die Ursache für den Quorumfehler korrigiert wurde, sind keine Änderungen am ursprünglichen Quorummodus und der Knotenabstimmungskonfiguration erforderlich.

    Andernfalls sollten Sie den neu wiederhergestellten Clusterknoten und Verfügbarkeitsreplikattopologie auswerten und bei Bedarf den Quorummodus und die Abstimmungszuweisungen für jeden Knoten ändern. Nicht wiederhergestellte Knoten sollten offline geschaltet werden oder einen Knotenabstimmungswert von 0 (Null) erhalten.

    Tipp

    Zu diesem Zeitpunkt könnte es so aussehen, als wären die Knoten und SQL Server-Instanzen im Cluster wieder zum normalen Betrieb zurückgekehrt. Allerdings besteht möglicherweise noch immer kein funktionsfähiges Quorum. Vergewissern Sie sich mithilfe des Failovercluster-Managers oder des AlwaysOn-Dashboards in SQL Server Management Studio oder der entsprechenden DMVs, dass ein Quorum wiederhergestellt wurde.

  5. Stellen Sie Datenbankreplikate der Verfügbarkeitsgruppen bei Bedarf wieder her. Datenbanken, die nicht zu einer Verfügbarkeitsgruppe gehören, sollten im Rahmen des regulären SQL Server-Startprozesses eigenständig wiederhergestellt werden und wieder online gehen.

    Sie können potenzielle Datenverluste und den Zeitaufwand des Wiederherstellungsvorgangs für die Verfügbarkeitsgruppenreplikate minimieren, indem Sie diese in der folgenden Reihenfolge wieder online schalten: primäres Replikat, synchrone sekundäre Replikate, asynchrone sekundäre Replikate.

Hinweis

Nach Verwendung des erzwungenen Quorums ist es erforderlich, ein erzwungenes Failover mit möglichen Datenverlust auszuführen, um die Verfügbarkeitsgruppe wieder online zu bringen. Weitere Informationen finden Sie unter Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server).

  1. Reparatur oder Austausch fehlerhafter Komponenten und erneute Überprüfung des Clusters. Nachdem Sie das System nach dem Auftreten der ursprünglichen Katastrophe und des Quorumfehlers wiederhergestellt haben, sollten Sie die fehlerhaften Knoten reparieren oder austauschen und die zugehörigen WSFC- und AlwaysOn-Konfigurationen entsprechend anpassen. Hierzu kann es erforderlich sein, Verfügbarkeitsgruppenreplikate zu löschen, Knoten aus dem Cluster zu entfernen oder die Software eines Knotens zu vereinfachen oder neu zu installieren.

    Sie müssen alle fehlerhaften Verfügbarkeitsreplikate reparieren oder entfernen. SQL Server schneidet das Transaktionsprotokoll nicht über den letzten bekannten Stand des am weitesten zurückliegenden Verfügbarkeitsreplikats hinaus ab. Wenn ein fehlerhaftes Replikat nicht repariert oder aus der Verfügbarkeitsgruppe entfernt wird, wachsen die Transaktionsprotokolle, und es besteht das Risiko, dass nicht mehr ausreichend Speicherplatz für die Transaktionsprotokolle der anderen Replikate verfügbar ist.

    Hinweis

    Wenn Sie den WSFC-Konfigurationsüberprüfungs-Assistenten ausführen, wenn im WSFC-Cluster ein Verfügbarkeitsgruppenlistener vorhanden ist, generiert der Assistent die folgende falsche Warnmeldung:

    „Die RegisterAllProviderIP-Eigenschaft für Netzwerkname 'Name:<Netzwerkname>' ist auf 1 festgelegt. Für die aktuelle Clusterkonfiguration muss dieser Wert auf 0 festgelegt werden.“

    Ignorieren Sie diese Meldung.

  2. Wiederholen Sie Schritt 4 nach Bedarf. Das Ziel besteht darin, erneut das für einen fehlerfreien Betrieb angemessene Maß an Fehlertoleranz und Hochverfügbarkeit wiederherzustellen.

  3. Führen Sie eine RPO/RTO-Analyse durch. Sie sollten SQL Server-Systemprotokolle, Datenbank-Timestamps und Windows-Ereignisprotokolle analysieren, um die Fehlerursache zu bestimmen und die tatsächlichen Wiederherstellungspunkt- und Wiederherstellungszeitdaten zu dokumentieren.

Verwandte Aufgaben

Verwandte Inhalte

Siehe auch

Windows Server-Failoverclustering (WSFC) mit SQL Server

  • Last updated on