Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen)

Artikel
01/07/2014

Im Kontext einer Verfügbarkeitsgruppe können die primäre und die sekundäre Rolle von Verfügbarkeitsreplikaten normalerweise im Rahmen des so genannten Failovers ausgetauscht werden. Failover können in drei Formen auftreten: automatisches Failover (ohne Datenverlust), geplantes manuelles Failover (ohne Datenverlust) und erzwungenes manuelles Failover (mit möglichem Datenverlust), in der Regel erzwungenes Failover genannt. Beim automatischen und geplanten manuellen Failover bleiben alle Daten erhalten. Eine Verfügbarkeitsgruppe führt ein Failover auf der Ebene des Verfügbarkeitsreplikats aus. Das heißt, eine Verfügbarkeitsgruppe führt ein Failover auf eines ihrer sekundären Replikate (das aktuelle Failoverziel) aus.

Hinweis
Probleme auf Datenbankebene, z. B. wenn eine Datenbank aufgrund des Verlusts einer Datendatei fehlerverdächtig wird, eine Datenbank gelöscht oder ein Transaktionsprotokoll beschädigt wird, führen nicht zum Failover einer Verfügbarkeitsgruppe.

Während des Failovers übernimmt das Failoverziel die primäre Rolle, stellt die zugehörigen Datenbanken wieder her und schaltet sie als neue primäre Datenbanken online. Das frühere primäre Replikat (falls verfügbar) wechselt zur sekundären Rolle, und seine Datenbanken werden zu sekundären Datenbanken. Diese Rollen können in Reaktion auf wiederholte Fehler oder zu Verwaltungszwecken hin und her (bzw. zu einem anderen Failoverziel) gewechselt werden.

Die von einem Verfügbarkeitsreplikat unterstützten Failoverformen werden von der Failovermodus-Eigenschaft angegeben. Die für die einzelnen Verfügbarkeitsreplikate möglichen Failovermodi hängen wie folgt vom Verfügbarkeitsmodus des Replikats ab:

Replikate mit synchronem Commit unterstützen zwei Einstellungen – automatisch oder manuell. Die "automatische" Einstellung unterstützt sowohl automatisches Failover als auch manuelles Failover. Um Datenverluste zu vermeiden, muss das Failoverziel beim automatischen und geplanten Failover ein sekundäres Replikat mit synchronem Commit und fehlerfreiem Synchronisierungsstatus sein (was darauf hinweist, dass jede sekundäre Datenbank auf dem Failoverziel mit der entsprechenden primären Datenbank synchronisiert ist). Wenn ein sekundäres Replikat keine dieser Bedingungen erfüllt, unterstützt es stets nur ein erzwungenes Failover. Beachten Sie, dass erzwungene Failover auch von Replikaten unterstützt werden, deren Rolle sich im RESOLVING-Status befindet.
Replikate mit asynchronem Commit unterstützen nur den manuellen Failovermodus. Da sie nie synchronisiert werden, unterstützen sie nur erzwungene Failover.

Hinweis
Nach einem Failover müssen Clientanwendungen, die auf die primären Datenbanken zugreifen müssen, eine Verbindung mit dem neuen primären Replikat herstellen. Außerdem können schreibgeschützte Clientanwendungen, wenn das neue sekundäre Replikat für den schreibgeschützten Zugriff konfiguriert ist, eine Verbindung mit dem Replikat herstellen. Weitere Informationen dazu, wie Clients eine Verbindung mit einer Verfügbarkeitsgruppe herstellen, finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Nach einem Failover müssen Clientanwendungen, die auf die primären Datenbanken zugreifen müssen, eine Verbindung mit dem neuen primären Replikat herstellen. Außerdem können schreibgeschützte Clientanwendungen, wenn das neue sekundäre Replikat für den schreibgeschützten Zugriff konfiguriert ist, eine Verbindung mit dem Replikat herstellen. Weitere Informationen dazu, wie Clients eine Verbindung mit einer Verfügbarkeitsgruppe herstellen, finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Abschnitte in diesem Thema:

Begriffe und Definitionen
Übersicht über Failover
Automatisches Failover
Geplantes manuelles Failover (ohne Datenverlust)
Erzwungenes Failover (mit möglichem Datenverlust)
Verwandte Aufgaben
Verwandte Inhalte

Begriffe und Definitionen

Automatisches Failover
Beim Verlust des primären Replikats tritt automatisch ein Failover statt. Automatisches Failover wird nur unterstützt, wenn das aktuelle primäre Replikat und ein sekundäres Replikat so konfiguriert sind, dass der Failovermodus auf AUTOMATIC festgelegt ist und das sekundäre Replikat derzeit synchronisiert wird. Wenn der Failovermodus entweder des primären oder des sekundären Replikats MANUAL ist, kann kein automatisches Failover auftreten.
Geplantes manuelles Failover (ohne Datenverlust)
Ein geplantes manuelles Failover oder manuelles Failover ist ein Failover, das in der Regel von einem Datenbankadministrator zu administrativen Zwecken initiiert wird. Ein geplantes manuelles Failover wird nur unterstützt, wenn sowohl das primäre Replikat als auch das sekundäre Replikat für den Modus mit synchronem Commit konfiguriert sind und das sekundäre Replikat derzeit synchronisiert wird (im Status SYNCHRONIZED). Wenn das sekundäre Zielreplikat synchronisiert ist, ist ein manuelles Failover (ohne Datenverlust) selbst bei einem Absturz des primären Replikats möglich, da die sekundären Datenbanken für ein Failover bereit sind. Ein Datenbankadministrator initiiert manuell ein manuelles Failover.
Erzwungenes Failover (mit möglichem Datenverlust)
Ein Failover, das von einem Datenbankadministrator initiiert werden kann, wenn kein sekundäres Replikat mit dem primären Replikat SYNCHRONISIERT ist oder das primäre Replikat nicht ausgeführt wird und kein sekundäres Replikat für ein Failover bereit ist. Ein erzwungenes Failover birgt das Risiko möglicher Datenverluste und sollte nur für die Notfallwiederherstellung verwendet werden. Erzwungenes Failover ist auch als erzwungenes manuelles Failover bekannt, da es nur manuell initiiert werden kann. Dies ist der einzige Failovertyp, der im Verfügbarkeitsmodus für asynchrone Commits unterstützt wird.
Satz automatischer Failover
Ein Paar von Verfügbarkeitsreplikaten (einschließlich des aktuellen primären Replikats) in einer Verfügbarkeitsgruppe, die für den synchronem Commitmodus mit automatischem Failover konfiguriert sind (sofern zutreffend). Ein Satz automatischer Failover wird nur wirksam, wenn das sekundäre Replikat derzeit mit dem primären Replikat synchronisiert wird.
Satz der Failover mit synchronem Commit
Ein Satz von zwei oder drei Verfügbarkeitsreplikaten (einschließlich des aktuellen primären Replikats) in einer Verfügbarkeitsgruppe, die für den synchronen Commitmodus (falls zutreffend) konfiguriert sind. Ein Satz der Failover mit synchronem Commit wird nur wirksam, wenn die sekundären Replikate für den manuellen Failovermodus konfiguriert sind und mindestens ein sekundäres Replikat derzeit mit dem primären Replikat SYNCHRONISIERT ist.
Satz für gesamtes Failover
Innerhalb einer angegebenen Verfügbarkeitsgruppe der Satz aller Verfügbarkeitsreplikate, deren Betriebszustand gerade ONLINE ist, unabhängig vom Verfügbarkeitsmodus und Failovermodus. Der Satz für gesamtes Failover wird relevant, wenn kein sekundäres Replikat gerade mit dem primären Replikat synchronisiert wird.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Übersicht über Failover

In der folgenden Tabelle ist zusammengefasst, welche Failovertypen unter unterschiedlichen Verfügbarkeits- und Failovermodi unterstützt werden. Für jede Paarung ergibt sich der effektive Verfügbarkeitsmodus und Failovermodus aus der Schnittmenge der Modi des primären Replikats sowie der Modi eines oder mehrerer sekundärer Replikate.

	Asynchroner Commit-Modus	Synchroner Commit-Modus mit manuellem Failovermodus	Synchroner Commit-Modus mit automatischem Failovermodus
Automatisches Failover	Nein	Nein	Ja
Geplantes manuelles Failover	Nein	Ja	Ja
Erzwungenes Failover	Ja	Ja	Ja*

* Wenn Sie einen Befehl für ein erzwungenes Failover für ein synchronisiertes sekundäres Replikat ausgeben, verhält sich das sekundäre Replikat genauso wie bei einem manuellen Failover.

Die Zeitdauer, für die Datenbank während eines Failovers nicht verfügbar ist, hängt vom Failovertyp und seiner Ursache ab.

Wichtig
Um Clientverbindungen außer für eigenständige Datenbanken nach dem Failover zu unterstützen, müssen auf einer früheren primären Datenbank definierte Anmeldungen und Aufträge für die neue primäre Datenbank manuell neu erstellt werden. Weitere Informationen finden Sie unter Verwaltung von Anmeldungen und Aufträgen für die Datenbanken einer Verfügbarkeitsgruppe (SQL Server).

Failoversätze

Welche Failoverarten für eine bestimmte Verfügbarkeitsgruppe möglich sind, richtet sich nach dem jeweiligen Failoversatz. Ein Failoversatz besteht aus dem primären Replikat und den sekundären Replikaten, die eine bestimmte, im Folgenden beschriebene Failoverart unterstützen:

**Satz automatischer Failover (optional): ** Ein Paar von Verfügbarkeitsreplikaten (einschließlich des aktuellen primären Replikats) in einer Verfügbarkeitsgruppe, die für den synchronen Commitmodus mit automatischem Failover (falls zutreffend) konfiguriert sind. Ein automatisches Failover ist nur wirksam, wenn das sekundäre Replikat derzeit mit dem primären Replikat synchronisiert wird.
**Satz der Failover mit synchronem Commit (optional): ** Ein Satz von zwei oder drei Verfügbarkeitsreplikaten (einschließlich des aktuellen primären Replikats) in einer Verfügbarkeitsgruppe, die für den synchronen Commitmodus (falls zutreffend) konfiguriert sind. Ein Failover mit synchronem Commit ist nur wirksam, wenn die sekundären Replikate für den manuellen Failovermodus konfiguriert sind und mindestens ein sekundäres Replikat derzeit mit dem primären Replikat synchronisiert wird.
**Satz für gesamtes Failover: ** Der Satz aller Verfügbarkeitsreplikate in einer Verfügbarkeitsgruppe, deren Betriebszustand derzeit ONLINE lautet, unabhängig vom Verfügbarkeitsmodus und Failovermodus. Der Satz für gesamtes Failover wird relevant, wenn derzeit kein sekundäres Replikat mit dem primären Replikat synchronisiert wird.

Wenn Sie ein Verfügbarkeitsreplikat für synchrone Commits mit automatischem Failover konfigurieren, wird das Verfügbarkeitsreplikat Teil von Satz automatischer Failover. Ob jedoch der Satz wirksam wird, hängt vom aktuellen primären Element ab. Die Failovertypen, die tatsächlich zu einem bestimmten Zeitpunkt möglich sind, hängen davon ab, welche Failoversätze aktuell wirksam sind.

Betrachten Sie z. B. eine Verfügbarkeitsgruppe mit vier Verfügbarkeitsreplikaten:

Replikat	Verfügbarkeitsmodus- und Failovermodus-Einstellungen
A	Synchroner Commit mit automatischem Failover
B	Synchroner Commit mit automatischem Failover
C	Synchroner Commit nur mit geplantem manuellem Failover
D	Asynchroner Commit (nur mit erzwungenem Failover)

Das Failoververhalten für jedes sekundäre Replikat hängt davon ab, welches Verfügbarkeitsreplikat gerade das primäre Replikat ist. Grundsätzlich ist für ein bestimmtes sekundäres Replikat das Failoververhalten der schlimmste Fall angesichts des aktuellen primären Replikats. In der folgenden Abbildung wird veranschaulicht, wie das Failoververhalten des sekundären Replikats in Abhängigkeit des aktuellen primären Replikats variiert und ob es für den asynchronen (nur mit erzwungenem Failover) oder den synchronen Commit-Modus (mit oder ohne manuellem Failover) konfiguriert ist.

Wie sich die Konfiguration des primären Replikats auf das Failover auswirkt

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Automatisches Failover

Ein automatisches Failover verursacht den automatischen Übergang eines qualifizierten sekundären Replikats zur primären Rolle, nachdem das primäre Replikat nicht mehr zur Verfügung steht. Ein automatisches Failover ist am besten geeignet, wenn der WSFC-Knoten, der das primäre Replikat hostet, lokal zum Knoten ist, der das sekundäre Replikat hostet. Das liegt daran, dass die Datensynchronisierung am besten bei niedrigen Nachrichtenlatenzzeiten zwischen Computern funktioniert und weil Clientverbindungen lokal hergestellt werden können.

In diesem Abschnitt:

Für ein automatisches Failover erforderliche Bedingungen
So funktioniert ein automatisches Failover
So aktivieren Sie ein automatisches Failover

Für ein automatisches Failover erforderliche Bedingungen

Ein automatisches Failover tritt nur unter den folgenden Bedingungen auf:

Ein Satz für automatische Failover ist vorhanden. Dieser Satz besteht aus einem primären Replikat und einem sekundären Replikat (dem Ziel des automatischen Failovers), die beide für den synchronen Commitmodus konfiguriert sind und auf automatisches Failover (AUTOMATIC) festgelegt sind. Wenn das primäre Replikat auf manuelle Failover (MANUAL) festgelegt ist, kann selbst dann kein automatisches Failover ausgeführt werden, wenn ein sekundäres Replikat auf automatisches Failover (AUTOMATIC) festgelegt ist.

Weitere Informationen finden Sie unter Verfügbarkeitsmodi (AlwaysOn-Verfügbarkeitsgruppen).

Das Ziel des automatischen Failovers weist einen fehlerfreien Synchronisierungsstatus auf (das heißt, dass jede sekundäre Datenbank im Failoverziel mit ihrer entsprechenden primären Datenbank synchronisiert wird).

Tipp
Durch AlwaysOn-Verfügbarkeitsgruppen wird der Zustand beider Replikate in einem Satz für automatische Failover überwacht. Wenn eines der Replikate fehlerhaft ist, wird der Zustand der Verfügbarkeitsgruppe auf CRITICAL festgelegt. Wenn das sekundäre Replikat fehlerhaft ist, kann kein automatisches Failover ausgeführt werden, da das Ziel für das automatische Failover nicht verfügbar ist. Wenn das primäre Replikat fehlerhaft ist, wird für die Verfügbarkeitsgruppe ein Failover auf das sekundäre Replikat ausgeführt. Für das automatische Failover ist erst wieder ein Ziel verfügbar, nachdem das vorherige primäre Replikat online geschaltet wurde. Um für den unwahrscheinlichen Fall, dass ein Folgefehler auftritt, in beiden Situationen Verfügbarkeit zu gewährleisten, wird empfohlen, ein anderes sekundäres Replikat als Ziel für das automatische Failover zu konfigurieren. Weitere Informationen finden Sie unter Verwenden von AlwaysOn-Richtlinien zum Anzeigen des Zustands einer Verfügbarkeitsgruppe (SQL Server) und Ändern des Failovermodus eines Verfügbarkeitsreplikats (SQL Server).

Durch AlwaysOn-Verfügbarkeitsgruppen wird der Zustand beider Replikate in einem Satz für automatische Failover überwacht. Wenn eines der Replikate fehlerhaft ist, wird der Zustand der Verfügbarkeitsgruppe auf CRITICAL festgelegt. Wenn das sekundäre Replikat fehlerhaft ist, kann kein automatisches Failover ausgeführt werden, da das Ziel für das automatische Failover nicht verfügbar ist. Wenn das primäre Replikat fehlerhaft ist, wird für die Verfügbarkeitsgruppe ein Failover auf das sekundäre Replikat ausgeführt. Für das automatische Failover ist erst wieder ein Ziel verfügbar, nachdem das vorherige primäre Replikat online geschaltet wurde. Um für den unwahrscheinlichen Fall, dass ein Folgefehler auftritt, in beiden Situationen Verfügbarkeit zu gewährleisten, wird empfohlen, ein anderes sekundäres Replikat als Ziel für das automatische Failover zu konfigurieren.

Weitere Informationen finden Sie unter Verwenden von AlwaysOn-Richtlinien zum Anzeigen des Zustands einer Verfügbarkeitsgruppe (SQL Server) und Ändern des Failovermodus eines Verfügbarkeitsreplikats (SQL Server).

Der WSFC-Cluster (Windows Server Failover Clustering) verfügt über ein Quorum. Weitere Informationen finden Sie unter WSFC-Quorummodi und Abstimmungskonfiguration (SQL Server).
Das primäre Replikat steht nicht mehr zur Verfügung, und die durch die flexible Failoverrichtlinie definierten Failover-Bedingungsebenen wurden erfüllt. Informationen zu Failover-Bedingungsebenen finden Sie unter Flexible Failoverrichtlinie für automatisches Failover einer Verfügbarkeitsgruppe (SQL Server).

So funktioniert ein automatisches Failover

Durch ein automatisches Failover wird die folgende Aktionskette ausgelöst:

Wenn die Serverinstanz, die das aktuelle primäre Replikat hostet, immer noch ausgeführt wird, ändert sie den Status der primären Datenbanken in DISCONNECTED und trennt alle Clientverbindungen.

Wenn Protokolldatensätze in Wiederherstellungswarteschlangen auf dem sekundären Zielreplikat warten, wendet das sekundäre Replikat die verbleibenden Protokolldatensätze an, um das Rollforward der sekundären Datenbanken fertig zu stellen.

Hinweis
Die zum Anwenden des Protokolls auf eine bestimmte Datenbank erforderliche Zeit hängt von der Systemgeschwindigkeit, der aktuellen Arbeitsauslastung und der Menge an Protokollen in der Wiederherstellungswarteschlange ab.

Das frühere sekundäre Replikat geht in die primäre Rolle über. Seine Datenbanken werden die primären Datenbanken. Das neue primäre Replikat führt so schnell wie möglich ein Rollback für alle Transaktionen aus, für die kein Commit ausgeführt wurde (die Rollbackphase der Wiederherstellung). Diese Transaktionen, für die kein Commit ausgeführt wurde, werden durch Sperren isoliert und ermöglichen ein Rollback im Hintergrund, während Clients die Datenbank verwenden. Für Transaktionen, für die ein Commit ausgeführt wurde, wird dabei kein Rollback durchgeführt.

Bis eine angegebene sekundäre Datenbank verbunden wird, ist sie kurzfristig als NOT_SYNCHRONIZED markiert. Bevor die Rollbackwiederherstellung gestartet wird, können sekundäre Datenbanken eine Verbindung mit den neuen primären Datenbanken herstellen und schnell in den Status SYNCHRONIZED übergehen. Der Idealfall für ein drittes Replikat mit synchronem Commit besteht normalerweise darin, dass das Replikat nach dem Failover in der sekundären Rolle verbleibt.
Später, wenn die Serverinstanz, die das frühere primäre Replikat hostet, neu gestartet wird, erkennt sie, dass jetzt ein anderes Verfügbarkeitsreplikat die primäre Rolle besitzt. Das frühere primäre Replikat geht in die sekundäre Rolle über, und seine Datenbanken werden sekundäre Datenbanken. Das neue sekundäre Replikat stellt eine Verbindung mit dem aktuellen primären Replikat her und fängt seine Datenbank so schnell wie möglich bis zu den aktuellen primären Datenbanken ab. Sobald das neue sekundäre Replikat seine Datenbanken erneut synchronisiert hat, ist ein neues Failover in umgekehrter Richtung möglich.

So konfigurieren Sie ein automatisches Failover

Ein Verfügbarkeitsreplikat kann konfiguriert werden, um ein automatisches Failover jederzeit zu unterstützen.

So konfigurieren Sie ein automatisches Failover

Stellen Sie sicher, dass das sekundäre Replikat konfiguriert ist, um den Verfügbarkeitsmodus mit synchronem Commit zu verwenden. Weitere Informationen finden Sie unter Ändern des Verfügbarkeitsmodus eines Verfügbarkeitsreplikats (SQL Server).
Legen Sie den Failovermodus auf automatisch fest. Weitere Informationen finden Sie unter Ändern des Failovermodus eines Verfügbarkeitsreplikats (SQL Server).
Ändern Sie optional die flexible Failoverrichtlinie der Verfügbarkeitsgruppe, und geben Sie die Fehlerarten an, durch die ein automatisches Failover verursacht werden kann. Weitere Informationen finden Sie unter Konfigurieren der flexiblen Failoverrichtlinie zum Steuern der Bedingungen für ein automatisches Failover (AlwaysOn-Verfügbarkeitsgruppen) und Failoverrichtlinie für Failoverclusterinstanzen.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Geplantes manuelles Failover (ohne Datenverlust)

Bei einem manuellen Failover geht ein synchronisiertes sekundäres Replikat zur primären Rolle über, nachdem ein Datenbankadministrator einen Befehl für ein manuelles Failover auf der Serverinstanz ausgibt, die das sekundäre Zielreplikat hostet. Zur Unterstützung eines manuellen Failovers müssen das sekundäre Replikat und das aktuelle primäre Replikat für den synchronen Commitmodus (falls zutreffend) konfiguriert sein. Jede sekundäre Datenbank auf dem Verfügbarkeitsreplikat muss mit der Verfügbarkeitsgruppe verknüpft und mit der entsprechenden primären Datenbank synchronisiert werden (d. h., das sekundäre Replikat muss synchronisiert werden). Damit wird sichergestellt, dass ein Commit für jede Transaktion, für die ein Commit auf einer früheren primären Datenbank ausgeführt wurde, auch auf der neuen primären Datenbank ausgeführt wurde. Daher sind die neuen primären Datenbanken mit den alten primären Datenbanken identisch.

In der folgenden Abbildung werden die Phasen eines geplanten Failovers veranschaulicht:

Vor dem Failover wird das primäre Replikat von der Serverinstanz auf Node01 gehostet.
Ein Datenbankadministrator initiiert ein geplantes Failover. Das Failoverziel ist das von der Serverinstanz auf Node02 gehostete Verfügbarkeitsreplikat.
Das Failoverziel (auf Node02) wird zum neuen primären Replikat. Da dies ein geplantes Failover ist, wechselt das frühere primäre Replikat während des Failovers zur sekundären Rolle und schaltet die zugehörigen Datenbanken unmittelbar als sekundäre Datenbanken online.

Abbildung eines geplanten manuellen Failovers

In diesem Abschnitt:

Für ein manuelles Failover erforderliche Bedingungen
So funktioniert ein manuelles Failover
Aufrechterhalten der Verfügbarkeit während Upgrades

Für ein manuelles Failover erforderliche Bedingungen

Um ein manuelles Failover zu unterstützen, muss das aktuelle primäre Replikat auf den Modus mit synchronem Commit festgelegt werden, und ein sekundäres Replikat muss folgende Bedingungen erfüllen:

Konfiguriert für den Modus mit synchronem Commit.
Derzeit mit dem primären Replikat synchronisiert.

Um ein Failover einer Verfügbarkeitsgruppe manuell auszuführen, müssen Sie mit dem sekundären Replikat verbunden sein, das das neue primäre Replikat wird.

Funktionsweise eines geplanten manuellen Failovers

Ein geplantes manuelles Failover, das auf dem sekundären Zielreplikat initiiert werden muss, initiiert die folgende Aktionskette:

Um sicherzustellen, dass keine neuen Benutzertransaktionen auf den ursprünglichen primären Datenbanken auftreten, sendet der WSFC-Cluster eine Anforderung an das primäre Replikat, in den Offlinemodus zu wechseln.

Wenn ein Protokoll in die Wiederherstellungswarteschlange einer sekundären Datenbank wartet, stellt das sekundäre Replikat das Rollforward dieser sekundären Datenbank fertig. Die erforderliche Zeit hängt von der Systemgeschwindigkeit, der aktuellen Arbeitsauslastung und der Menge der Protokolle in der Wiederherstellungswarteschlange ab. Um die aktuelle Größe der Wiederherstellungswarteschlange festzustellen, verwenden Sie den Leistungsindikator Recovery Queue. Weitere Informationen finden Sie unter SQL Server, Datenbankreplikat.

Hinweis
Die Failoverzeit kann durch die Begrenzung der Größe der Wiederherstellungswarteschlange reguliert werden. Das führt allerdings möglicherweise zu einem langsameren primären Replikat, damit vom sekundären Replikat die Geschwindigkeit gehalten werden kann.

Das sekundäre Replikat wird das neue primäre Replikat, und das frühere primäre Replikat wird das neue sekundäre Replikat.
Das neue primäre Replikat führt für alle Transaktionen, für die noch kein Commit ausgeführt wurde, ein Rollback aus und schaltet seine Datenbanken als primäre Datenbanken online. Alle sekundären Datenbanken werden kurzfristig als NOT SYNCHRONIZED markiert, bis sie eine Verbindung mit den neuen primären Datenbanken herstellen und damit synchronisiert werden. Für Transaktionen, für die ein Commit ausgeführt wurde, wird dabei kein Rollback durchgeführt.
Wenn das frühere primäre Replikat wieder online geschaltet wird, nimmt es die sekundäre Rolle an, und die frühere primäre Datenbank wird zur sekundären Datenbank. Das neue sekundäre Replikat synchronisiert schnell die neuen sekundären Datenbanken erneut mit den entsprechenden primären Datenbanken.

Hinweis

Sobald das neue sekundäre Replikat die Datenbanken erneut synchronisiert hat, ist ein neues Failover möglich, allerdings in umgekehrter Richtung.

Hinweis
Sobald das neue sekundäre Replikat die Datenbanken erneut synchronisiert hat, ist ein neues Failover möglich, allerdings in umgekehrter Richtung.

Nach dem Failover müssen von Clients erneut Verbindungen mit der aktuellen primären Datenbank hergestellt werden. Weitere Informationen finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Aufrechterhalten der Verfügbarkeit während Upgrades

Der Datenbankadministrator für die Verfügbarkeitsgruppen kann die Datenbankverfügbarkeit mithilfe von manuellen Failovers aufrechterhalten, wenn Sie Hardware oder Software aktualisieren. Um eine Verfügbarkeitsgruppe für Softwareupgrades zu verwenden, muss die Serverinstanz und/oder der Computerknoten, der das sekundäre Zielreplikat hostet, die Upgrades bereits empfangen haben. Weitere Informationen finden Sie unter Upgrade und Update von Verfügbarkeitsgruppenservern bei minimaler Downtime und minimalem Datenverlust.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Erzwungenes Failover (mit möglichem Datenverlust)

Das Erzwingen eines Failovers einer Verfügbarkeitsgruppe (mit möglichem Datenverlust) ist eine Notfallwiederherstellungsmethode, mit der Sie ein sekundäres Replikat als betriebsbereiten Standbyserver verwenden können. Da es beim Erzwingen des Failovers zu Datenverlusten kommen kann, sollte diese Methode unter Vorbehalt und selten angewendet werden. Es wird empfohlen, das Failover nur dann zu erzwingen, wenn Sie den Dienst für die Verfügbarkeitsdatenbanken sofort wiederherstellen müssen und bereit sind, das Risiko des Datenverlustes in Kauf zu nehmen. Weitere Informationen zu den Voraussetzungen und Empfehlungen zum Erzwingen des Failovers sowie ein Beispielszenario, in dem zur Wiederherstellung nach einem schwerwiegenden Fehler ein erzwungenes Failover verwendet wird, finden Sie unter Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server).

Vorsicht
Für das Erzwingen eines Failovers muss der WSFC-Cluster über Quorum verfügen. Weitere Informationen zum Konfigurieren und Erzwingen von Quorum finden Sie unter Windows Server-Failoverclustering (WSFC) mit SQL Server.

In diesem Abschnitt:

So funktioniert ein erzwungenes Failover
Risiken beim Erzwingen des Failovers
Warum nach Erzwingen des Quorums ein erzwungenes Failover erforderlich ist
Möglichen Datenverlust nachverfolgen
Umgang mit potenziellem Datenverlust

So funktioniert ein erzwungenes Failover

Durch ein erzwungenes Failover wird der Wechsel der primären Rolle zu einem Zielreplikat initiiert, dessen Rolle sich im SECONDARY- oder RESOLVING-Status befindet. Das Failoverziel wird zum neuen primären Replikat und stellt seine Datenbankkopien sofort den Clients zur Verfügung. Wenn das frühere primäre Replikat verfügbar wird, geht es in die sekundäre Rolle über, und seine Datenbanken werden sekundäre Datenbanken.

Alle sekundären Datenbanken (einschließlich der früheren primären Datenbanken, wenn sie verfügbar werden) haben den Status SUSPENDED. In Abhängigkeit früherer Datensynchronisierungsstatus einer angehaltenen sekundären Datenbank empfiehlt es sich möglicherweise, fehlende übergebene Daten für die primäre Datenbank zu retten. Auf einem sekundären Replikat, das für schreibgeschützten Zugriff konfiguriert ist, können Sie die sekundären Datenbanken abfragen, um fehlende Daten manuell zu ermitteln. Danach können Sie Transact-SQL-Anweisungen ausgeben, um alle notwendigen Änderungen für die neuen primären Datenbanken vorzunehmen.

Risiken beim Erzwingen des Failovers

Sie sollten unbedingt bedenken, dass durch das Erzwingen des Failovers Daten verloren gehen können. Zu einem Datenverlust kann es kommen, weil das Zielreplikat nicht mit dem primären Replikat kommunizieren und somit nicht sicherstellen kann, dass die Datenbanken synchronisiert sind. Durch das Erzwingen des Failovers wird eine neue Wiederherstellungsverzweigung gestartet. Da sich die ursprünglichen primären Datenbanken und sekundären Datenbanken auf verschiedenen Wiederherstellungsverzweigungen befinden, enthält jede Datenbank nun Daten, die in der jeweils anderen Datenbank nicht vorhanden sind: Jede ursprüngliche primäre Datenbank enthält die Änderungen, die noch nicht aus der Sendewarteschlange an die frühere sekundäre Datenbank gesendet wurden (die nicht gesendeten Protokolle). Die früheren sekundären Datenbanken enthalten die Änderungen, die nach dem Erzwingen des Failovers vorgenommen wurden.

Wird das Failover aufgrund eines Fehlers des primären Replikats erzwungen, hängt der potenzielle Datenverlust davon ab, ob Transaktionsprotokolle vorhanden sind, die vor dem Fehler nicht an das sekundäre Replikat gesendet wurden. Im asynchronen Commit-Modus besteht immer die Möglichkeit, dass sich nicht gesendete Protokolle ansammeln. Im synchronen Commit-Modus ist dies nur bis zum Synchronisieren der sekundären Datenbanken möglich.

In der folgenden Tabelle werden die Möglichkeiten eines Datenverlusts für eine bestimmte Datenbank auf dem Replikat, wofür Sie ein Failover ausführen, zusammengefasst.

Verfügbarkeitsmodus des sekundären Replikats	Ist die Datenbank synchronisiert?	Besteht die Möglichkeit eines Datenverlusts?
Synchroner Commit	Ja	Nein
Synchroner Commit	Nein	Ja
Asynchroner Commit	Nein	Ja

Sekundäre Datenbanken verfolgen nur zwei Wiederherstellungsverzweigungen nach. Wenn Sie also mehrere erzwungene Failover ausführen, kann eine sekundäre Datenbank, für die die Datensynchronisierung mit dem vorherigen erzwungenen Failover gestartet wurde, u. U. nicht fortgesetzt werden. In diesem Fall müssen alle sekundären Datenbanken, die nicht fortgesetzt werden können, aus der Verfügbarkeitsgruppe entfernt und der Verfügbarkeitsgruppe wieder hinzugefügt werden, nachdem sie bis zum richtigen Zeitpunkt wiederhergestellt wurden. Da eine Wiederherstellung nicht über mehrere Wiederherstellungsverzweigungen ausgeführt werden kann, sollten Sie unbedingt eine Protokollsicherung erstellen, nachdem Sie mehr als ein erzwungenes Failover ausgeführt haben.

Warum nach Erzwingen des Quorums ein erzwungenes Failover erforderlich ist

Nachdem Sie das Quorum (erzwungenes Quorum) im WSFC-Cluster erzwungen 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. Normale Failover müssen nach einem erzwungenen Quorum verhindert werden, da ein nicht synchronisiertes sekundäres Replikat andernfalls im neu konfigurierten WSFC-Cluster als synchronisiert angezeigt werden könnte.

Beispiel: Ein WSFC-Cluster, das eine Verfügbarkeitsgruppe auf drei Knoten hostet: Knoten A hostet das primäre Replikat. Knoten B und Knoten C hosten jeweils ein sekundäres Replikat. Knoten C wird vom WSFC-Cluster getrennt, während das lokale sekundäre Replikat SYNCHRONISIERT wird. Die Knoten A und B weisen weiterhin ein fehlerfreies Quorum auf. Die Verfügbarkeitsgruppe bleibt online. Auf Knoten A akzeptiert das primäre Replikat weiterhin Updates. Auf Knoten B wird das sekundäre Replikat weiterhin mit dem primären Replikat synchronisiert. Das sekundäre Replikat auf Knoten C wird nicht mehr synchronisiert und fällt zunehmend hinter das primäre Replikat zurück. Da Knoten C getrennt wurde, bleibt das Replikat jedoch fälschlicherweise im Status SYNCHRONIZED.

Wenn das Quorum verloren geht und dann auf Knoten A erzwungen wird, sollte der Synchronisierungsstatus der Verfügbarkeitsgruppe im WSFC-Cluster richtig sein. Das sekundäre Replikat auf Knoten C sollte den Status UNSYNCHRONIZED aufweisen. Wenn jedoch ein Quorum auf Knoten C erzwungen wird, ist die Synchronisierung der Verfügbarkeitsgruppe falsch. Der Synchronisierungsstatus im Cluster entspricht dem Status, als Knoten C getrennt wurde. Das sekundäre Replikat auf Knoten C weist fälschlicherweise den Status SYNCHRONIZED auf. Da geplante manuelle Failover die Sicherheit der Daten gewährleisten, darf eine Verfügbarkeitsgruppe nach dem Erzwingen eines Quorums nicht wieder online geschaltet werden.

Möglichen Datenverlust nachverfolgen

Wenn der WSFC-Cluster ein fehlerfreies Quorum aufweist, können Sie das aktuelle Datenverlustrisiko fürDatenbanken einschätzen. Für ein gegebenes sekundäres Replikat hängt das aktuelle Datenverlustrisiko davon ab, wie groß die Verzögerung der lokalen sekundären Datenbanken gegenüber den entsprechenden primären Datenbanken ist. Da die Verzögerung im Verlauf der Zeit variiert, wird empfohlen, den potenziellen Datenverlust für Ihre nicht synchronisierten sekundären Datenbanken regelmäßig nachzuverfolgen. Eine Nachverfolgung der Verzögerung umfasst den Vergleich der LSN des letzten Commits mit der Zeit des letzten Commits für jede primäre Datenbank und ihre sekundären Datenbanken wie folgt:

Stellen Sie eine Verbindung mit dem primären Replikat her.
Führen Sie eine Abfrage der Spalten last_commit_lsn (LSN der letzten Transaktion, für die ein Commit ausgeführt wurde) und last_commit_time (Zeitpunkt des letzten Commits) der dynamischen Verwaltungssicht sys.dm_hadr_database_replica_states durch.
Vergleichen Sie die Werte, die für jede primäre Datenbank und ihre sekundären Datenbanken zurückgegeben werden. Der Unterschied zwischen den LSNs des letzten Commits gibt die Verzögerung an.
Sie können eine Warnung ausgeben, wenn die Verzögerung für eine Datenbank oder einen Satz Datenbanken die gewünschte maximale Verzögerung für einen bestimmten Zeitraum überschreitet. Beispielsweise kann die Abfrage durch einen Auftrag ausgeführt werden, der einmal pro Minute für jede primäre Datenbank ausgeführt wird. Wenn der Unterschied zwischen last_commit_time einer primären Datenbank und einer ihrer sekundären Datenbanken das Recovery Point Objective (RPO) (beispielsweise 5 Minuten) seit der letzten Ausführung des Jobs überschreitet, kann der Job eine Warnung ausgeben.

Wichtig
Wenn der WSFC-Cluster kein Quorum aufweist oder das Quorum erzwungen wurden, sind last_commit_lsn und last_commit_time NULL. Weitere Informationen dazu, wie Sie Datenverluste vermeiden können, nachdem Sie ein Quorum erzwungen haben, finden Sie unter "Möglichkeiten zum Vermeiden von Datenverlust nach dem Erzwingen eines Quorums" in Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server).

Wenn der WSFC-Cluster kein Quorum aufweist oder das Quorum erzwungen wurden, sind last_commit_lsn und last_commit_time NULL. Weitere Informationen dazu, wie Sie Datenverluste vermeiden können, nachdem Sie ein Quorum erzwungen haben, finden Sie unter "Möglichkeiten zum Vermeiden von Datenverlust nach dem Erzwingen eines Quorums" in Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server).

Umgang mit potenziellem Datenverlust

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.

Sobald das frühere primäre Replikat verfügbar ist, können Sie versuchen, den potenziellen Datenverlust zu verwalten, falls die Datenbanken unbeschädigt sind. Der jeweilige Ansatz für die Verwaltung des potenziellen Datenverlusts hängt davon ab, ob das ursprüngliche primäre Replikat eine Verbindung mit dem neuen primären Replikat hergestellt hat. Vorausgesetzt, dass das ursprüngliche primäre Replikat auf die neue primäre Instanz zugreifen kann, wird die Verbindung automatisch und transparent wiederhergestellt.

Das ursprüngliche primäre Replikat hat eine Verbindung wiederhergestellt

Normalerweise stellt das ursprüngliche primäre Replikat nach einem Fehler beim Neustarten rasch die Verbindung zu seinem Partner wieder her. Beim Wiederherstellen der Verbindung wird das ursprüngliche primäre Replikat zum sekundären Replikat. Seine Datenbanken werden die sekundären Datenbanken und erhalten den Status SUSPENDED. Es wird nur dann ein Rollback der neuen sekundären Datenbanken ausgeführt, wenn Sie sie fortsetzen.

Der Zugriff auf die angehaltenen Datenbanken ist jedoch nicht möglich; deshalb können Sie sie nicht überprüfen, um festzustellen, welche Daten beim Fortsetzen einer bestimmten Datenbank verloren gehen würden. Die Entscheidung, ob eine sekundäre Datenbank fortgesetzt oder entfernt werden soll, hängt somit wie folgt davon ab, ob Sie bereit sind, Datenverluste in Kauf zu nehmen:

Wenn der Verlust von Daten inakzeptabel ist, sollten Sie die Datenbanken aus der Verfügbarkeitsgruppe entfernen, um die Daten zu retten.

Der Datenbankadministrator kann jetzt die früheren primären Datenbanken wiederherstellen und versuchen, die Daten wiederherzustellen, die verloren gegangen wären. Wenn eine frühere primäre Datenbank jedoch online geschaltet wird, weicht sie von der aktuellen primären Datenbank ab. Daher muss der Datenbankadministrator entweder die entfernte Datenbank oder die aktuelle primäre Datenbank für Clients sperren, um weitere Abweichungen der Datenbanken sowie Clientfailoverprobleme zu vermeiden.
Wenn der Verlust von Daten für Ihre Geschäftsziele akzeptabel ist, können Sie die sekundären Datenbanken fortsetzen.

Beim Fortsetzen einer neuen sekundären Datenbank wird ein Rollback der Datenbank als erster Schritt zum Synchronisieren ausgeführt. Waren zum Zeitpunkt des Fehlers Protokolldatensätze in der Sendewarteschlange enthalten, gehen die entsprechenden Transaktionen verloren, selbst wenn ein Commit für sie ausgeführt wurde.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]

Das ursprüngliche primäre Replikat hat keine Verbindung wiederhergestellt

Wenn Sie zeitweise verhindern können, dass das ursprüngliche primäre Replikat wieder eine Verbindung über das Netzwerk mit dem primären Replikat herstellt, können Sie die ursprünglichen primären Datenbanken überprüfen und so feststellen, welche Daten im Falle einer Fortsetzung verloren gehen würden.

Der potenzielle Datenverlust ist akzeptabel

Lassen Sie zu, dass das ursprüngliche primäre Replikat erneut eine Verbindung mit dem neuen primären Replikat herstellt. Durch das erneute Verbinden werden die neuen sekundären Datenbanken angehalten. Zum Starten der Datensynchronisierung in einer Datenbank setzen Sie deren Ausführung einfach fort. Das neue sekundäre Replikat löscht die ursprüngliche Wiederherstellungsverzweigung für diese Datenbank, wobei alle Transaktionen verloren gehen, die nie an das frühere sekundäre Replikat gesendet wurden bzw. von ihm empfangen wurden.
Ist der Datenverlust nicht akzeptabel, gehen Sie folgendermaßen vor:

Wenn die ursprüngliche primäre Datenbank wichtige Daten enthält, die verloren gehen würden, wenn Sie die angehaltene Datenbank fortsetzen, können Sie Daten auf der ursprünglichen primären Datenbank durch Entfernen der Datenbank aus der Verfügbarkeitsgruppe beibehalten. Dies bewirkt, dass die Datenbank den Status RESTORING erhält. Sie sollten in diesem Fall versuchen, das Protokollfragment der entfernten Datenbank zu sichern. Sie können dann die aktuelle primäre (die frühere sekundäre Datenbank) durch Exportieren der in der ursprünglichen primären Datenbank zu erhaltenden Daten und Importieren der Daten in die aktuelle primäre Datenbank aktualisieren. Es wird empfohlen, so schnell wie möglich eine vollständige Datenbanksicherung der aktualisierten primären Datenbank zu erstellen.

Sie können dann auf der Serverinstanz, die das neue sekundäre Replikat hostet, die angehaltene sekundäre Datenbank löschen und eine neue sekundäre Datenbank durch das Wiederherstellen dieser Sicherung (und mindestens einer nachfolgenden Protokollsicherung) mit RESTORE WITH NORECOVERY erstellen. Es wird empfohlen, zusätzliche Protokollsicherungen der aktuellen primären Datenbanken bis zum Fortsetzen der entsprechenden sekundären Datenbanken hinauszuzögern.

Vorsicht
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.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird [Nach oben]