Manuelles Failover
Durch das manuelle Failover werden die Clients von der Datenbank getrennt und die Rollen der Partner umgekehrt. Nur der Modus mit hoher Sicherheit unterstützt ein manuelles Failover.
.gif "Hinweis") Hinweis |
|---|
In diesem Thema wird davon ausgegangen, dass Sie mit dem Modus mit hoher Sicherheit vertraut sind. Weitere Informationen finden Sie unter Synchrone Datenbankspiegelung (Modus für hohe Sicherheit). |
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.
.gif "Geplantes manuelles Failover")
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:
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.
Vom Spiegelserver wird die Protokollsequenznummer (LSN, Log Sequence Number) des letzten vom Prinzipal empfangenen Protokolldatensatzes als Failover-LSN aufgezeichnet.
HinweisUm die LSN anzuzeigen, wählen Sie die mirroring_failover_lsn-Spalte von sys.database_mirroring (Transact-SQL) aus.
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.
HinweisZur Feststellung der aktuellen Größe der Wiederholungswarteschlange verwenden Sie den Leistungsindikator Wiederholungswarteschlange im Datenbankspiegelungs-Leistungsobjekt. (Weitere Informationen finden Sie unter Überwachen der Datenbankspiegelung.)
Der Spiegelserver wird zum neuen Prinzipalserver, und der vorherige Prinzipalserver wird zum neuen Spiegelserver.
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.
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.
HinweisSobald 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.