Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server)

In diesem Thema wird beschrieben, wie ein erzwungenes Failover (mit möglichem Datenverlust) in einer AlwaysOn-Verfügbarkeitsgruppe mit SQL Server Management Studio, Transact-SQL oder PowerShell in SQL Server 2012 ausgeführt wird. Ein erzwungenes Failover ist eine Art manuelles Failover, das strikt für die Notfallwiederherstellung bestimmt ist, wenn ein geplantes manuelles Failover nicht möglich ist. Wenn Sie ein Failover zu einem unsynchronisierten sekundären Replikat erzwingen, ist Datenverlust möglich. Daher empfehlen wir dringend, dass Sie nur dann ein Failover erzwingen, wenn Sie den Dienst für die Verfügbarkeitsgruppe sofort wiederherstellen müssen und Datenverluste riskieren möchten.

Nach einem erzwungenen Failover wird das Failoverziel, zu dem ein Failover der Verfügbarkeitsgruppe ausgeführt wurde, zum neuen primären Replikat. Die sekundären Datenbanken in den verbleibenden sekundären Replikaten werden angehalten und müssen manuell fortgesetzt werden. Wenn das frühere primäre Replikat verfügbar wird, geht es in die sekundäre Rolle über, sodass die früheren primären Datenbanken zu sekundären Datenbanken werden und in den Status SUSPENDED übergehen. Bevor Sie eine angegebene sekundäre Datenbank fortsetzen, können Sie möglicherweise verlorene Daten wiederherstellen. Beachten Sie jedoch, dass die Transaktionsprotokollkürzung auf einer angegebenen primären Datenbank verzögert wird, solange eine ihrer sekundären Datenbanken angehalten ist.

Wichtig
Eine Datensynchronisierung mit der primären Datenbank findet erst dann statt, wenn die sekundäre Datenbank fortgesetzt wird. Weitere Informationen zum Fortsetzen einer sekundären Datenbank finden Sie weiter unten in diesem Artikel unter Wichtige Aufgaben nach einem erzwungenen Failover.

Ein erzwungenes Failover ist in den folgenden Notfallsituationen notwendig:

• Nachdem Sie dem WSFC-Cluster das Quorum (erzwungenes Quorum) aufgezwungen haben, müssen Sie für jede Verfügbarkeitsgruppe ein Failover erzwingen (mit möglichem Datenverlust). Das Erzwingen eines Failovers ist erforderlich, da der wirkliche Status der WSFC-Clusterwerte verloren gegangen sein könnte. Sie können jedoch Datenverlust vermeiden, wenn Sie auf der Serverinstanz, die das Replikat gehostet hat, das vor dem Erzwingen des Quorums das primäre Replikat war, oder zu dem sekundären Replikat, das vor dem Erzwingen des Quorums synchronisiert wurde, ein Failover erzwingen können. Weitere Informationen finden Sie unter Möglichkeiten zum Vermeiden von Datenverlust nach dem Erzwingen eines Quorums weiter unten in diesem Thema.

  Wichtig
  Wenn das Quorum auf natürlichem Wege wiedererlangt und nicht erzwungen wird, durchlaufen die Verfügbarkeitsreplikate die normale Wiederherstellung. Wenn das primäre Replikat immer nach dem Wiedererlangen des Quorums noch nicht verfügbar ist, können Sie zu einem synchronisierten sekundären Replikat ein geplantes manuelles Failover ausführen.

  Informationen zur Erzwingung des Quorums finden Sie unter WSFC-Notfallwiederherstellung durch erzwungenes Quorum (SQL Server). Informationen dazu, warum nach dem Erzwingen des Quorums das Erzwingen eines Failovers erforderlich ist, finden Sie unter Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

• Wenn das primäre Replikat nicht verfügbar wird, wenn der WSFC-Cluster ein fehlerfreies Quorum hat, können Sie zu irgendeinem Replikat, dessen Rolle den Status SECONDARY oder RESOLVING aufweist, ein Failover erzwingen (mit möglichem Datenverlust). Erzwingen Sie wenn möglich ein Failover zu einem sekundären Replikat mit synchronem Commit, das synchronisiert wurde, als das primäre Replikat verloren ging.

  Tipp
  Wenn der WSFC-Cluster ein fehlerfreies Quorum hat und Sie auf einem synchronisierten sekundären Replikat einen Befehl zum Erzwingen eines Failovers ausgeben, führt das Replikat eigentlich ein geplantes manuelles Failover aus.

Hinweis
Weitere Informationen zu den erforderlichen Komponenten und den Empfehlungen zum Erzwingen von Failover und für ein Beispielszenario, in dem zur Wiederherstellung von einem schwerwiegenden Fehler ein erzwungenes Failover verwendet wird, finden Sie unter Beispielszenario: Wiederherstellen nach einem schwerwiegenden Fehler mithilfe eines erzwungenen Failovers weiter unten in diesem Thema.

• Vorbereitungen:  

  Einschränkungen

  Voraussetzungen

  Empfehlungen

  Möglichkeiten zum Vermeiden von Datenverlust nach dem Erzwingen eines Quorums

  Sicherheit

• Erzwingen eines Failovers (mit möglichem Datenverlust) mit:  

  SQL Server Management Studio

  Transact-SQL

  PowerShell

• Nachverfolgung:  Wichtige Aufgaben nach einem erzwungenen Failover

• Beispielszenario:  Wiederherstellen nach einem schwerwiegenden Fehler mithilfe eines erzwungenen Failovers

• Verwandte Aufgaben

• Verwandte Inhalte

Vorbereitungen

Einschränkungen

• Sie können nur dann kein erzwungenes Failover ausführen, wenn der WSFC-Cluster über kein Quorum verfügt.

• Während des erzwungenen Failovers einer Verfügbarkeitsgruppe können Datenverluste auftreten. Außerdem können, wenn das primäre Replikat beim Initiieren eines erzwungenen Failovers ausgeführt wird, Clients immer noch mit früheren primären Datenbanken verbunden sein. Daher empfehlen wir dringend, dass Sie nur dann ein Failover erzwingen, wenn das primäre Replikat nicht mehr ausgeführt wird und Sie bereitwillig Datenverluste riskieren, um den Zugriff auf Datenbanken in der Verfügbarkeitsgruppe wiederherzustellen.

• Wenn eine sekundäre Datenbank den Status REVERTING oder INITIALIZING aufweist, würde das Erzwingen eines Failovers dazu führen, dass die Datenbank nicht als primäre Datenbank gestartet wird. Befindet sich die Datenbank im Status INTIAILIZGING, müssen Sie die fehlenden Protokolldatensätze von einer Datenbanksicherung übernehmen oder die Datenbank von Grund auf neu vollständig wiederherstellen. Wenn die Datenbank den Status REVERTING aufweist, müssen Sie die Datenbank vollständig aus einer Sicherungskopie wiederherstellen.

• Ein Failoverbefehl gibt einen Wert zurück, sobald das Failoverziel den Befehl akzeptiert hat. Die Datenbankwiederherstellung tritt jedoch asynchron auf, nachdem die Verfügbarkeitsgruppe aufgehört hat, ein Failover auszuführen.

• Datenbankübergreifende Konsistenz zwischen Datenbanken innerhalb der Verfügbarkeitsgruppe wird beim Failover nicht beibehalten.

  Hinweis
  Datenbankübergreifende Transaktionen und verteilte Transaktionen werden von AlwaysOn-Verfügbarkeitsgruppen nicht unterstützt. Weitere Informationen finden Sie unter Datenbankübergreifende Transaktionen nicht unterstützt für Datenbankspiegelungs- oder AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Voraussetzungen

• Der WSFC-Cluster verfügt über ein Quorum. Wenn der Cluster über kein Quorum verfügt, siehe WSFC-Notfallwiederherstellung durch erzwungenes Quorum (SQL Server).

• Sie müssen eine Verbindung mit einer Serverinstanz herstellen können, die ein Replikat hostet, dessen Rolle den Status SECONDARY oder RESOLVING aufweist.

Empfehlungen

• Erzwingen Sie kein Failover, wenn das primäre Replikat noch ausgeführt wird.

• Sie sollten nach Möglichkeit ein Failover nur für ein Failoverziel erzwingen, dessen Datenbanken über den Status NOT SYNCHRONIZED, SYNCHRONIZED oder SYNCHRONIZING verfügen. Informationen über die Auswirkungen beim Erzwingen eines Failovers, wenn sich eine sekundäre Datenbank im Status INTIAILIZGING oder REVERTING befindet, finden Sie im obigen Thema Einschränkungen.

• In der Regel sollte die Latenzzeit einer angegebenen sekundären Datenbank relativ zur primären Datenbank auf anderen sekundären Replikaten mit asynchronem Commit ähnlich sein. Wenn jedoch ein Failover erzwungen wird, kann Datenverlust eine wichtige Überlegung sein. Nehmen Sie sich daher entsprechend Zeit, um die relative Latenzzeit der Kopien der Datenbanken auf anderen sekundären Replikaten zu bestimmen. Um zu bestimmen, welche Kopie einer angegebenen sekundären Datenbank die niedrigste Latenzzeit hat, vergleichen Sie ihre Protokollende-LSNs. Eine höhere Protokollende-LSN deutet auf eine kürzere Latenzzeit hin.

  Tipp

  Um Protokollende-LSNs zu vergleichen, stellen Sie jeweils eine Verbindung zu einem sekundären Online-Replikat her, und fragen Sie sys.dm_hadr_database_replica_states für den end_of_log_lsn-Wert jeder lokalen sekundären Datenbank ab. Vergleichen Sie dann die Protokollende-LSNs der anderen Kopien jeder Datenbank. Beachten Sie, dass unterschiedliche Datenbanken ihre höchsten LSNs auf anderen sekundären Replikaten haben können. In diesem Fall hängt das am besten geeignete Failoverziel von der relativen Wichtigkeit ab, die Sie den Daten in den anderen Datenbanken geben. Das heißt, für welche dieser Datenbanken möchten Sie einen möglichen Datenverlust am meisten minimieren?

• Wenn Clients eine Verbindung zur ursprünglichen primären Instanz herstellen können, bringt ein erzwungenes Failover ein gewisses Split-Brain-Risiko mit sich. Daher wird nachdrücklich empfohlen, vor dem Erzwingen des Failovers zu verhindern, dass Clients auf das ursprüngliche primäre Replikat zugreifen. Andernfalls ist es nach dem Erzwingen des Failovers möglich, dass die ursprünglichen primären Datenbanken und die aktuellen primären Datenbanken unabhängig voneinander aktualisiert werden.

Möglichkeiten zum Vermeiden von Datenverlust nach dem Erzwingen eines Quorums

Unter einigen Fehlerbedingungen können Sie nach dem Verlust des Quorums einen Datenverlust wie folgt verhindern:

• Wenn das ursprüngliche primäre Replikat online geschaltet wird

  Wenn das Quorum verloren gegangen ist und durch das Erzwingen des WSFC-Quorums der Clusterknoten wiederhergestellt wird, der das primäre Replikat einer Verfügbarkeitsgruppe hostet, können Sie Datenverlust für diese Verfügbarkeitsgruppe verhindern. Stellen Sie eine Verbindung mit dem primären Replikat her und führen Sie ein erzwungenes Failover (FAILOVER_ALLOW_DATA_LOSS) aus. Dies schaltet das primäre Replikat wieder online. Da Sie das erzwungene Failover zum ursprünglichen primären Replikat ausführen, gibt es keinen Datenverlust.

• Wenn ein synchronisiertes sekundäres Replikat mit synchronem Commit online geschaltet wird

  Wenn das Quorum verloren gegangen ist und durch das Erzwingen des WSFC-Quorums der Clusterknoten wiederhergestellt wird, der das synchronisierte sekundäre Replikat einer Verfügbarkeitsgruppe hostet, sollten Sie Datenverlust für diese Verfügbarkeitsgruppe verhindern können. Wenn der wiederhergestellte Knoten zum Zeitpunkt des Quorumsverlusts online war, können Sie bestimmen, ob Datenverlust auf einer gegebenen Datenbank auftreten konnte, indem Sie die Spalte is_failover_ready der dynamischen Verwaltungssicht sys.dm_hadr_database_replica_cluster_states abfragen. Geben Sie z. B. für eine Serverinstanz mit dem Namen sql108w2k8r22 die folgende Abfrage aus:

  SELECT * FROM sys.dm_hadr_database_replica_cluster_states
     WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas 
        WHERE replica_server_name ='sql108w2k8r22')
  

  Vorsicht

  Wenn der wiederhergestellte Knoten zum Zeitpunkt des Quorumsverlusts nicht online war, gibt is_failover_ready möglicherweise nicht den Ist-Zustand des Clusters zum Zeitpunkt, als das primäre Replikat offline ging, wieder. Daher ist der is_failover_ready-Wert nur dann hilfreich, wenn der Hostknoten zum Zeitpunkt des Auftretens des Fehlers online war. Weitere Informationen finden Sie unter "Warum nach Erzwingen des Quorums ein erzwungenes Failover erforderlich ist" unter Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

  Wenn is_failover_ready = 1, wird die Datenbank im Cluster als synchronisiert gekennzeichnet und ist zu einem Failover bereit. Wenn is_failover_ready auf jeder Datenbank für ein gegebenes sekundäres Replikat = 1 ist, können Sie auf diesem sekundären Replikat ein erzwungenes Failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) ohne Datenverlust ausführen. Das synchronisierte sekundäre Replikat wird in der primären Rolle online geschaltet, das heißt, als neues primäres Replikat, wobei alle Daten intakt sind.

  Wenn is_failover_ready = 0, wird die Datenbank im Cluster nicht als synchronisiert gekennzeichnet und ist nicht zu einem geplanten manuellen Failover bereit. Wenn Sie ein Failover zum sekundären Hostreplikat erzwingen, gehen Daten auf dieser Datenbank verloren.

  Hinweis

  Wenn Sie ein Failover zu einem sekundären Replikat erzwingen, hängt der Umfang des Datenverlusts davon ab, wie weit das Failoverziel hinter dem primären Replikat zurückbleibt. Wenn der WSFC-Cluster über kein Quorum verfügt oder ein Quorum erzwungen wurde, können Sie den Umfang des potenziellen Datenverlusts nicht bewerten. Beachten Sie jedoch, dass Sie sobald der WSFC-Cluster ein fehlerfreies Quorum wiedererlangt hat mit der Nachverfolgung des potenziellen Datenverlusts beginnen können. Weitere Informationen finden Sie im Abschnitt "Nachverfolgen des potenziellen Datenverlusts" unter Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

Sicherheit

Berechtigungen

Erfordert die ALTER AVAILABILITY GROUP-Berechtigung für die Verfügbarkeitsgruppe, die CONTROL AVAILABILITY GROUP-Berechtigung, die ALTER ANY AVAILABILITY GROUP-Berechtigung oder die CONTROL SERVER-Berechtigung.

[Nach oben]

Verwenden von SQL Server Management Studio

So erzwingen Sie ein Failover (mit möglichem Datenverlust)

1. Stellen Sie im Objekt-Explorer eine Verbindung zu einer Serverinstanz her, die ein Replikat hostet, dessen Rolle in der Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden muss, den SECONDARY-Status oder RESOLVING-Status aufweist, und erweitern Sie die Serverstruktur.

2. Erweitern Sie den Knoten Hohe Verfügbarkeit (immer aktiviert) und den Knoten Verfügbarkeitsgruppen.

3. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden soll, und wählen Sie den Befehl Failover aus.

4. Dadurch wird der Assistent für das Failover von Verfügbarkeitsgruppen gestartet. Weitere Informationen finden Sie unter Verwenden des Assistenten für Failover-Verfügbarkeitsgruppen (SQL Server Management Studio).

5. Führen Sie nach dem Erzwingen des Failovers für eine Verfügbarkeitsgruppe die notwendigen Nachverfolgungsschritte aus. Weitere Informationen finden Sie weiter unten in diesem Thema unter Nachverfolgung: Wichtige Aufgaben nach einem erzwungenen Failover.

[Nach oben]

Verwenden von Transact-SQL

So erzwingen Sie ein Failover (mit möglichem Datenverlust)

1. Stellen Sie eine Verbindung zu einer Serverinstanz her, die ein Replikat hostet, dessen Rolle in der Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden muss, den SECONDARY-Status oder RESOLVING-Status aufweist.

2. Verwenden Sie die ALTER AVAILABILITY GROUP-Anweisung wie folgt:

   ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

   Dabei ist group_name der Name der Verfügbarkeitsgruppe.

   Im folgenden Beispiel erzwingt die AccountsAG-Verfügbarkeitsgruppe ein Failover zum lokalen sekundären Replikat.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Führen Sie nach dem Erzwingen des Failovers für eine Verfügbarkeitsgruppe die notwendigen Nachverfolgungsschritte aus. Weitere Informationen finden Sie weiter unten in diesem Thema unter Nachverfolgung: Wichtige Aufgaben nach einem erzwungenen Failover.

[Nach oben]

Verwenden von PowerShell

So erzwingen Sie ein Failover (mit möglichem Datenverlust)

1. Ändern Sie das Verzeichnis (cd) zu einer Serverinstanz, die ein Replikat hostet, dessen Rolle in der Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden muss, den SECONDARY-Status oder RESOLVING-Status aufweist.

2. Verwenden Sie auf eine der folgenden Arten Switch-SqlAvailabilityGroup-Cmdlet mit dem AllowDataLoss-Parameter:

   • -AllowDataLoss

     Standardmäßig wird durch -AllowDataLoss-Parameter Switch-SqlAvailabilityGroup aufgefordert, Sie daran zu erinnern, dass das Erzwingen eines Failovers zum Verlust von Transaktionen, für die kein Commit ausgeführt wurde, führen kann, und die Bestätigung anzufordern. Geben Sie J ein, um den Vorgang fortzusetzen. Geben Sie N ein, um den Vorgang abzubrechen.

     Im folgenden Beispiel wird ein erzwungenes Failover (mit möglichem Datenverlust) der Verfügbarkeitsgruppe MyAg zum sekundären Replikat auf der Serverinstanz SecondaryServer\InstanceName ausgeführt. Sie werden aufgefordert, diesen Vorgang zu bestätigen.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss -Force

     Um ein erzwungenes Failover ohne Bestätigung zu initiieren, geben Sie den -AllowDataLoss-Parameter und den -Force-Parameter an. Dies ist nützlich, wenn Sie den Befehl in ein Skript einschließen und es ohne Benutzerinteraktion ausführen möchten. Verwenden Sie jedoch die -Force-Option mit Vorsicht, da ein erzwungenes Failover zum Datenverlust in Datenbanken führen kann, die an der Verfügbarkeitsgruppe teilnehmen.

     Im folgenden Beispiel wird ein erzwungenes Failover (mit möglichem Datenverlust) der Verfügbarkeitsgruppe MyAg zur Serverinstanz SecondaryServer\InstanceName ausgeführt. Durch die -Force-Option wird die Bestätigung für diesen Vorgang unterdrückt.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Hinweis
   Um die Syntax eines Cmdlets anzuzeigen, verwenden Sie das Get-Help-Cmdlet in der SQL Server PowerShell-Umgebung. Weitere Informationen finden Sie unter Aufrufen der SQL Server PowerShell-Hilfe.

3. Führen Sie nach dem Erzwingen des Failovers für eine Verfügbarkeitsgruppe die notwendigen Nachverfolgungsschritte aus. Weitere Informationen finden Sie weiter unten in diesem Thema unter Nachverfolgung: Wichtige Aufgaben nach einem erzwungenen Failover.

Einrichten und Verwenden des SQL Server PowerShell-Anbieters

• SQL Server PowerShell-Anbieter

[Nach oben]

Nachverfolgung: Wichtige Aufgaben nach einem erzwungenen Failover

1. Nach einem erzwungenen Failover wird das sekundäre Replikat, zu dem Sie ein Failover ausgeführt haben, das neue primäre Replikat. Damit Clients auf dieses Verfügbarkeitsreplikat zugreifen können, müssen Sie jedoch eventuell das WSFC-Quorum neu konfigurieren oder die Verfügbarkeitsmodus-Konfiguration der Verfügbarkeitsgruppe wie folgt anpassen:

   • Wenn Sie ein Failover außerhalb des Satz automatischer Failover ausgeführt haben: Passen Sie die Quorumabstimmungen der WSFC-Knoten an die Konfiguration der neuen Verfügbarkeitsgruppe an. Wenn der WSFC-Knoten, der das sekundäre Zielreplikat hostet, nicht über eine WSFC-Quorumabstimmung verfügt, müssen Sie unter Umständen das WSFC-Quorum erzwingen.

     Hinweis
     Ein Satz automatischer Failover ist nur vorhanden, wenn zwei Verfügbarkeitsreplikate (einschließlich des vorherigen primären Replikats) für den Modus für synchrone Commits mit automatischem Failover konfiguriert sind.

     So passen Sie Quorumabstimmungen an

     • Anzeigen von Cluster-Quorum-NodeWeight-Einstellungen

     • Konfigurieren von Cluster-Quorum-NodeWeight-Einstellungen

     • Erzwingen des Starts eines Clusters ohne Quorum

   • Wenn Sie ein Failover außerhalb des Satz der Failover mit synchronem Commit ausgeführt haben: Es wird empfohlen, den Verfügbarkeitsmodus und Failovermodus auf dem neuen primären Replikat und auf übrigen sekundären Replikaten an die gewünschte Konfiguration des Failovers für synchrone Commits und des automatischen Failovers anzupassen.

     Hinweis
     Ein Satz der Failover mit synchronem Commit ist nur vorhanden, wenn das aktuelle primäre Replikat für den Modus für synchrone Commits konfiguriert wird.

     So ändern Sie den Verfügbarkeitsmodus und Failovermodus

     • Ändern des Verfügbarkeitsmodus eines Verfügbarkeitsreplikats (SQL Server)

     • Ändern des Failovermodus eines Verfügbarkeitsreplikats (SQL Server)

2. Nach einem erzwungenen Failover werden alle sekundären Datenbanken angehalten. Dies schließt die früheren primären Datenbanken ein, nachdem das frühere primäre Replikat wieder online geschaltet wurde und ermittelt, dass es jetzt ein sekundäres Replikat ist. Sie müssen jede angehaltene Datenbank einzeln auf jedem sekundären Replikat manuell fortsetzen.

   Beim Fortsetzen initiiert eine sekundäre Datenbank die Datensynchronisierung mit der entsprechenden primären Datenbank. Die sekundäre Datenbank führt einen Rollback für alle Protokolldatensätze aus, für die nie ein Commit in der neuen primären Datenbank ausgeführt wurde. Wenn Sie daher Bedenken wegen eines möglichen Datenverlustes in den primären Datenbanken nach dem Failover haben, sollten Sie versuchen, eine Datenbank-Momentaufnahme der angehaltenen Datenbanken in einer der sekundären Datenbanken mit synchronem Commit zu erstellen.

   Wichtig
   Die Transaktionsprotokollkürzung wird auf einer primären Datenbank verzögert, solange eine ihrer sekundären Datenbanken angehalten ist. Der Synchronisierungszustand eines sekundären Replikats mit synchronem Commit kann auch keinen Übergang zu HEALTHY durchführen, solange alle lokalen Datenbanküberreste angehalten sind.

   So erstellen Sie eine Datenbankmomentaufnahme

   • Erstellen einer Datenbankmomentaufnahme (Transact-SQL)

   So setzen Sie eine Verfügbarkeitsdatenbank fort

   • Fortsetzen einer Verfügbarkeitsdatenbank (SQL Server)

   Vorsicht

   Warten Sie vor dem Versuch, nach dem Fortsetzen aller sekundären Datenbanken erneut ein Failover der Gruppe auszuführen, bis jede sekundäre Datenbank auf dem nächsten Failoverziel den Status SYNCHRONIZING erhält. Falls eine Datenbank noch nicht den Status SYNCHRONIZING aufweist, wird verhindert, dass diese Datenbank als primäre Datenbank online geschaltet wird. Zum erneuten Einrichten der Datensynchronisierung für die Datenbank kann das Wiederherstellen von Transaktionsprotokollen, das Wiederherstellen einer vollständigen Datenbanksicherung oder ein Failover zurück zum vorherigen primären Replikat erforderlich sein.

3. Wenn ein fehlerhaftes Verfügbarkeitsreplikat nicht zur Verfügbarkeitsgruppe oder zu spät zurückgegeben wird, um Kürzungen von Transaktionsprotokollen auf der neuen primären Datenbank zu verzögern, sollten Sie das fehlerhafte Replikat aus der Verfügbarkeitsgruppe entfernen, um zu verhindern, dass für die Protokolldateien nicht genügend Speicherplatz vorhanden ist.

   So entfernen Sie ein sekundäres Replikat

   • Entfernen einer sekundären Replikats aus einer Verfügbarkeitsgruppe (SQL Server)

4. Wenn auf ein erzwungenes Failover ein oder mehrere zusätzliche Failover folgen, führen Sie nach jedem zusätzlichen erzwungenen Failover in der Serie eine Protokollsicherung aus. Weitere Informationen zur Ursache finden Sie unter "Risiken beim Erzwingen des Failovers" im Abschnitt "Erzwungenes manuelles Failover (mit möglichem Datenverlust)" von Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

   So führen Sie eine Protokollsicherung aus

   • Sichern eines Transaktionsprotokolls (SQL Server)

[Nach oben]

Beispielszenario: Wiederherstellen nach einem schwerwiegenden Fehler mithilfe eines erzwungenen Failovers

Wenn das primäre Replikat fehlschlägt und kein synchronisiertes sekundäres Replikat verfügbar ist, kann das Erzwingen eines Failovers für die Verfügbarkeitsgruppe unter Umständen eine angemessene Reaktion sein. Ob das Erzwingen eines Failovers angebracht ist, ist von folgenden Dingen abhängig: (1) Ob Sie davon ausgehen, dass das primäre Replikat für einen längeren Zeitraum offline ist als die Vereinbarung zum Servicelevel (SLA) vorsieht, und (2) ob Sie bereit sind, einen möglichen Datenverlust zu riskieren, um primäre Datenbanken schnell verfügbar zu machen. Wenn Sie entscheiden, dass ein Failover für eine Verfügbarkeitsgruppe erzwungen werden muss, ist der eigentliche erzwungene Failover lediglich ein Schritt von vielen.

Um die Schritte zu erläutern, die für einen erzwungenen Failover zur Wiederherstellung nach einem schwerwiegenden Fehler erforderlich sind, enthält dieses Thema ein mögliches Szenario für die Wiederherstellung im Notfall. Das Beispielszenario enthält eine Verfügbarkeitsgruppe, deren ursprüngliche Topologie aus einem Hauptrechenzentrum besteht, das drei Verfügbarkeitsreplikate mit synchronem Commit hostet, einschließlich des primären Replikats, und aus einem Remoterechenzentrum, das zwei sekundäre Replikate mit asynchronem Commit hostet. Die folgende Abbildung veranschaulicht die ursprüngliche Topologie dieser beispielhaften Verfügbarkeitsgruppe. Die Verfügbarkeitsgruppe wird von einem Multisubnetz-WSFC-Cluster mit drei Knoten im Hauptrechenzentrum (Knoten 01, Knoten 02 und Knoten 03) und zwei Knoten in einem Remoterechenzentrum (Knoten 04 und Knoten 05) gehostet.

Das Hauptrechenzentrum wird unerwartet heruntergefahren. Seine drei Verfügbarkeitsreplikate werden offline geschaltet, und die Datenbanken sind nicht mehr verfügbar. Die folgende Abbildung veranschaulicht die Auswirkungen dieses Fehlers auf die Topologie der Verfügbarkeitsgruppe.

Der Datenbankadministrator bestimmt, dass die beste Reaktion ein erzwungener Failover der Verfügbarkeitsgruppe auf eines der sekundären Replikate mit asynchronem Commit ist. In diesem Beispiel werden die typischen Schritte eines erzwungenen Failovers der Verfügbarkeitsgruppe auf ein Remotereplikat und das Zurückkehren der Verfügbarkeitsgruppe zu ihrer ursprünglichen Topologie veranschaulicht.

Die hier beschriebene Reaktion auf einen Fehler besteht aus den folgenden zwei Phasen:

• Reagieren auf den schwerwiegenden Fehler im Hauptrechenzentrum

• Zurückkehren der Verfügbarkeitsgruppe zu ihrer ursprünglichen Topologie

Reagieren auf den schwerwiegenden Fehler im Hauptrechenzentrum

Die folgende Abbildung veranschaulicht die Abfolge von Aktionen, die als Reaktion auf einen schwerwiegenden Fehler im Hauptrechenzentrum beim Remoterechenzentrum ausgeführt werden.

Die Schritte in dieser Abbildung geben die folgenden Schritte an:

[Nach oben]

Zurückkehren der Verfügbarkeitsgruppe zu ihrer ursprünglichen Topologie

Die folgende Abbildung veranschaulicht die Abfolge von Aktionen, durch die die Verfügbarkeitsgruppe in ihre ursprüngliche Topologie zurückkehrt, nachdem das Hauptrechenzentrum wieder online gekommen ist und die WSFC-Knoten die Kommunikation mit dem WSFC-Cluster wieder eingerichtet haben.

Wichtig

Wenn das WSFC-Clusterquorum erzwungen wurde, könnte beim Neustart der Offlineknoten ein neues Quorum gebildet werden, wenn die folgenden Bedinungen erfüllt sind: (a) Es gibt keine Netzwerkkonnektivität zwischen einem der Knoten im erzwungenen Quorumsatz und (b) die neu gestarteten Knoten stellen die Mehrheit der Clusterknoten dar. Dies würde zu einer so genannten "split brain"-Bedingung führen, in der die Verfügbarkeitsgruppe zwei unabhängige primäre Replikate besitzen würde, eines in jedem Rechenzentrum. Lesen Sie vor dem Erzwingen eines Quorums zur Erstellung eines Minderheitsquorumsatzes die Informationen in WSFC-Notfallwiederherstellung durch erzwungenes Quorum (SQL Server).

Die Schritte in dieser Abbildung geben die folgenden Schritte an:

	Schritt	Links
1.	Die Knoten im Hauptrechenzentrum kommen wieder online und richten die Kommunikation mit dem WSFC-Cluster erneut ein. Ihre Verfügbarkeitsreplikate werden als sekundäre Replikate mit angehaltenen Datenbanken online geschaltet, und der Datenbankadministrator muss jede von diesen Datenbanken so bald wie möglich manuell fortsetzen.	Fortsetzen einer Verfügbarkeitsdatenbank (SQL Server) Tipp Wenn Sie Bedenken bezüglich eines möglichen Datenverlustes in den primären Datenbanken nach dem Failover haben, sollten Sie versuchen, eine Momentaufnahme der Datenbank in den angehaltenen Datenbanken auf der sekundären Datenbank mit synchronem Commit zu erstellen. Bedenken Sie, dass die Transaktionsprotokollkürzung auf einer primären Datenbank verzögert wird, solange eine ihrer sekundären Datenbanken angehalten ist. Der Synchronisierungszustand des sekundären Replikats mit synchronem Commit kann auch keinen Übergang zu HEALTHY durchführen, solange alle lokalen Datenbanküberreste angehalten sind.
2.	Wenn die Datenbanken fortgesetzt werden, ändert der Datenbankadministrator das neue primäre Replikat vorübergehend in den Modus für synchrone Commits. Dies umfasst zwei Schritte: Ändern eines Offlineverfügbarkeitsreplikats in den Modus für asynchrone Commits. Ändern des neuen primären Replikats in den Modus mit synchronem Commit. Hinweis Durch diesen Schritt können fortgesetzte sekundäre Datenbanken mit synchronem Commit den Status SYNCHRONIZED annehmen.	Ändern des Verfügbarkeitsmodus eines Verfügbarkeitsreplikats (SQL Server)
3.	Nachdem das sekundäre Replikat mit synchronem Commit in Knoten 03 (das ursprüngliche primäre Replikat) den HEALTHY-Synchronisierungsstatus annimmt, führt der Datenbankadministrator ein geplantes manuelles Failover zu diesem Replikat auf, damit es wieder das primäre Replikat wird. Das Replikat in Knoten 04 wird wieder ein sekundäres Replikat.	sys.dm_hadr_database_replica_states (Transact-SQL) Verwenden von AlwaysOn-Richtlinien zum Anzeigen des Zustands einer Verfügbarkeitsgruppe (SQL Server) Ausführen eines geplanten manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server)
4.	Der Datenbankadministrator stellt eine Verbindung mit dem neuen primären Replikat her und: Ändert das frühere primäre Replikat (im Remoterechenzentrum) zurück in den Modus für asynchrone Commits. Ändert das sekundäre Replikat mit asynchronem Commit im Hauptrechenzentrum zurück in den Modus für synchrone Commits.	Ändern des Verfügbarkeitsmodus eines Verfügbarkeitsreplikats (SQL Server)

[Nach oben]

Verwandte Aufgaben

So passen Sie Quorumabstimmungen an

• Anzeigen von Cluster-Quorum-NodeWeight-Einstellungen

• Konfigurieren von Cluster-Quorum-NodeWeight-Einstellungen

• Erzwingen des Starts eines Clusters ohne Quorum

Geplantes manuelles Failover:

• Ausführen eines geplanten manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server)

• Verwenden des Assistenten für Failover-Verfügbarkeitsgruppen (SQL Server Management Studio)

So beheben Sie Probleme:

• Problembehandlung für die AlwaysOn-Verfügbarkeitsgruppenkonfiguration (SQL Server)

• Problembehandlung bei einem fehlgeschlagenen Vorgang zum Hinzufügen einer Datei (AlwaysOn-Verfügbarkeitsgruppen)

[Nach oben]

Verwandte Inhalte

• **Blogs: **

  SQL Server AlwaysOn-Teamblogs: Der offizielle SQL Server AlwaysOn-Teamblog

  CSS SQL Server-Technikblogs

• **Whitepapers: **

  Microsoft SQL Server AlwaysOn-Lösungshandbuch zu hoher Verfügbarkeit und Notfallwiederherstellung

  Microsoft-Whitepapers für SQL Server 2012

  Whitepapers des SQL Server-Kundenberatungsteams

[Nach oben]

Siehe auch

Konzepte

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Verfügbarkeitsmodi (AlwaysOn-Verfügbarkeitsgruppen)

Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen)

Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)

Überwachen von Verfügbarkeitsgruppen (SQL Server)

Windows Server-Failoverclustering (WSFC) mit SQL Server