Manuelles Failover

Aufrechterhalten der Verfügbarkeit während Updates

Vom Datenbankadministrator kann das manuelle Failover zum Aktualisieren der Hardware oder Software ohne Einbußen bei der Verfügbarkeit verwendet werden. Um die Datenbankspiegelung für Softwareaktualisierungen zu verwenden, müssen die Updates bereits auf dem Spiegelserver und/oder dem System vorhanden sein.

Hinweis
Die Datenbankspiegelung sollte in der Lage sein, ein paralleles Update auszuführen. Dies wird jedoch nicht garantiert, da zukünftige Änderungen unbekannt sind. Weitere Informationen finden Sie unter Vorgehensweise: Minimieren der Ausfallzeit von gespiegelten Datenbanken beim Aktualisieren von Serverinstanzen.

Die folgende Abbildung veranschaulicht ein manuelles Failover, bei dem während der Aktualisierung einer Datenbankserverinstanz die Datenbank verfügbar bleibt. Nach dem Abschluss der Aktualisierung kann vom Administrator optional ein Failover zurück zur Originalserverinstanz durchgeführt werden. Dies ist nützlich, wenn der Administrator die Spiegelungssitzung beenden und den Spiegelserver anderweitig verwenden möchte. Auf diese Weise kann eine einzelne Serverinstanz wiederholt beim Aktualisieren einer Reihe von Datenbankserverinstanzen verwendet werden.

Für ein manuelles Failover erforderliche Bedingungen

Für das manuelle Failover ist die Transaktionssicherheitseinstellung FULL erforderlich (d. h., der Modus für hohe Sicherheit). Wenn die Partner verbunden sind und die Datenbank bereits synchronisiert ist, wird das manuelle Failover unterstützt.

So funktioniert ein manuelles Failover

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

1. Vom Prinzipalserver werden Clients von der Prinzipaldatenbank getrennt. Das Ende des Protokolls wird an den Spiegelserver gesendet, und in Vorbereitung auf den Wechsel der Spiegelrolle wird der Status der Prinzipaldatenbank auf SYNCHRONIZING festgelegt.

2. Vom Spiegelserver wird die Protokollsequenznummer (LSN, Log Sequence Number) des letzten vom Prinzipal empfangenen Protokolldatensatzes als Failover-LSN aufgezeichnet.

   Hinweis
   Um die LSN anzuzeigen, wählen Sie die mirroring_failover_lsn-Spalte von sys.database_mirroring (Transact-SQL) aus.

3. Wenn ein Protokoll in der Wiederholungswarteschlange wartet, stellt der Spiegelserver das Rollforward der Spiegeldatenbank fertig. Die erforderliche Zeit hängt von der Systemgeschwindigkeit, der aktuellen Arbeitsauslastung und der Menge der Protokolle in der Wiederholungswarteschlange ab. Für den synchronen Betriebsmodus kann die Failoverzeit durch die Begrenzung der Wiederholungswarteschlangengröße reguliert werden. Das führt allerdings möglicherweise zu einem langsameren Prinzipalserver, damit vom Spiegelserver die Geschwindigkeit gehalten werden kann.

   Hinweis
   Zur Feststellung der aktuellen Größe der Wiederholungswarteschlange verwenden Sie den Leistungsindikator Wiederholungswarteschlange im Datenbankspiegelungs-Leistungsobjekt. (Weitere Informationen finden Sie unter Überwachen der Datenbankspiegelung.)

4. Der Spiegelserver wird zum neuen Prinzipalserver, und der vorherige Prinzipalserver wird zum neuen Spiegelserver.

5. Vom neuen Prinzipalserver wird für alle Transaktionen, für die kein Commit ausgeführt worden ist, ein Rollback ausgeführt und die Kopie der Datenbank als Prinzipaldatenbank online gestellt.

6. Der vorherige Prinzipal übernimmt die Spiegelrolle, und die vorherige Prinzipaldatenbank wird zur Spiegeldatenbank. Vom neuen Spiegelserver wird die neue Spiegeldatenbank schnell mit der neuen Prinzipaldatenbank erneut synchronisiert.

   Hinweis
   Sobald vom neuen Spiegelserver die Datenbanken erneut synchronisiert worden sind, ist ein neues Failover möglich, allerdings in umgekehrter Richtung.

Nach dem Failover müssen von Clients erneut Verbindungen mit der aktuellen Prinzipaldatenbank hergestellt werden. Weitere Informationen finden Sie unter Herstellen von Clientverbindungen mit einer gespiegelten Datenbank.

Siehe auch

Konzepte