Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen)

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:

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.

[Nach oben]

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

• 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).

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

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

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

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

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

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

So konfigurieren Sie ein automatisches Failover

1. 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).

2. Legen Sie den Failovermodus auf automatisch fest. Weitere Informationen finden Sie unter Ändern des Failovermodus eines Verfügbarkeitsreplikats (SQL Server).

3. Ä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.

[Nach oben]

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.

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

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

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

3. Das sekundäre Replikat wird das neue primäre Replikat, und das frühere primäre Replikat wird das neue sekundäre Replikat.

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

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

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

[Nach oben]

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.

Hinweis
Durch das Failover von Verfügbarkeitsgruppen sollte ein paralleles Upgrade unterstützt werden, dies wird jedoch nicht garantiert.

[Nach oben]

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.

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.

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.

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.

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:

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

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

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

4. 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).

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

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.

[Nach oben]