Automatisches Failover
Automatisches Failover wird nur in Datenbank-Spiegelungssitzungen unterstützt, die mit einem Zeugen im Modus für hohe Sicherheit ausgeführt werden (Modus für hohe Sicherheit mit automatischem Failover). Im Modus für hohe Sicherheit mit automatischem Failover wird nach dem Synchronisieren der Datenbank ein automatisches Failover ausgeführt, wenn die Prinzipaldatenbank ausfällt. Bei einem automatischen Failover übernimmt der Spiegelserver die Rolle des Prinzipalservers und schaltet die eigene Datenbankkopie als Prinzipaldatenbank online. Aufgrund der Voraussetzung, dass die Datenbank synchronisiert sein muss, werden Datenverluste während des Failovers verhindert, da für jede Transaktion, für die auf der Prinizipaldatenbank ein Commit ausgeführt wird, auch ein Commit auf der Spiegeldatenbank ausgeführt wird.
Damit das automatische Failover eine Verbesserung der Verfügbarkeit bedeutet, müssen sich Spiegel- und Prinzipaldatenbank auf verschiedenen Computern befinden.
Für ein automatisches Failover erforderliche Bedingungen
Für automatisches Failover müssen folgende Bedingungen erfüllt sein:
Die Datenbank-Spiegelungssitzung muss im Modus für hohe Sicherheit ausgeführt werden und einen Zeugen besitzen. Weitere Informationen finden Sie unter Synchrone Datenbankspiegelung (Modus für hohe Sicherheit).
Die Spiegeldatenbank muss bereits synchronisiert sein. Dadurch wird sichergestellt, dass sämtliche an den Spiegelserver gesendeten Protokolleinträge auf den Datenträger geschrieben wurden.
Die Kommunikation des Prinzipalservers mit dem Rest der Datenbankspiegelungskonfiguration wurde unterbrochen, während der Spiegelserver und der Zeugenserver das Quorum behalten. Wenn jedoch alle Serverinstanzen die Kommunikation verlieren und der Zeugenserver und der Spiegelserver später die Kommunikation wieder aufnehmen, erfolgt kein automatisches Failover.
.gif "Hinweis")
HinweisWeitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit.
Der Spiegelserver hat den Verlust des Prinzipalservers erkannt.
Wie der Spiegelserver einen Ausfall des Prinzipalservers erkennt, hängt davon ab, ob es sich um einen Hardware- oder Softwarefehler handelt. Weitere Informationen finden Sie unter Mögliche Fehler während der Datenbankspiegelung.
So funktioniert ein automatisches Failover
Unter den oben genannten Bedingungen wird beim automatischen Failover die folgende Aktionsfolge initiiert:
Wird der Prinzipalserver noch immer ausgeführt, ändert er den Status der Prinzipaldatenbank in DISCONNECTED und trennt alle Clientverbindungen zur Prinzipaldatenbank.
Der Zeugen- und der Spiegelserver registrieren, dass der Prinzipalserver nicht verfügbar ist.
Wartet ein Protokoll in der Wiederholungswarteschlange, schließt der Spiegelserver den Rollforward der Spiegeldatenbank ab.
HinweisDie zum Anwenden des Protokolls erforderliche Zeit hängt von der Systemgeschwindigkeit, der aktuellen Arbeitsauslastung und der Menge an Protokollen in der Wiederholungswarteschlange ab.
Die frühere Spiegeldatenbank wird als neue Prinzipaldatenbank online geschaltet. Bei der Wiederherstellung werden alle Transaktionen, für die kein Commit ausgeführt wurde, möglichst schnell durch ein Rollback dieser Transaktionen bereinigt. Diese Transaktionen werden durch Sperren isoliert.
Wenn sich der frühere Prinzipalserver der Sitzung wieder anschließt, erkennt er, dass sein Failoverpartner jetzt die Prinzipalrolle besitzt. Der frühere Prinzipalserver übernimmt die Rolle des Spiegels und macht seine Datenbank zur Spiegeldatenbank. Der neue Spiegelserver synchronisiert die neue Spiegeldatenbank so schnell wie möglich mit der Prinzipaldatenbank. Sobald der neue Spiegelserver die Datenbanken synchronisiert hat, ist ein Failover wieder möglich, jedoch in umgekehrter Richtung.
In der folgenden Abbildung wird eine einzelne Instanz von automatischem Failover veranschaulicht.
.gif "Automatisches Failover")
Anfänglich besitzen alle drei Server eine Verbindung (die Sitzung verfügt über ein vollständiges Quorum). Partner_A ist der Prinzipalserver und Partner_B ist der Spiegelserver. Partner_A (oder die Prinzipaldatenbank auf Partner_A) steht nicht länger zur Verfügung. Der Zeugenserver und Partner_B erkennen, dass der Prinzipalserver nicht mehr verfügbar ist, die Sitzung behält jedoch das Quorum. Partner_B wird zum Prinzipalserver und macht seine Kopie der Datenbank als neue Prinzipaldatenbank verfügbar. Schließlich stellt Partner_A wieder eine Verbindung zur Sitzung her und erkennt, dass Partner_B jetzt die Prinzipalrolle besitzt. Partner_A übernimmt dann die Spiegelrolle.
Nach dem Failover müssen die Clients erneut eine Verbindung zur aktuellen Prinzipaldatenbank herstellen. Weitere Informationen finden Sie unter Herstellen von Clientverbindungen mit einer gespiegelten Datenbank.
| Hinweis |
|---|
Transaktionen, die mit dem Microsoft Distributed Transaction Coordinator vorbereitet wurden, für die beim Auftreten eines Failovers jedoch noch kein Commit ausgeführt wurde, werden nach dem Failover der Datenbank als abgebrochen betrachtet. |
Deaktivieren des automatischen Failovers mithilfe von SQL Server Management Studio
Öffnen Sie zum Deaktivieren des automatischen Failovers die Seite Spiegelung unter den Datenbankeigenschaften, und ändern Sie den Betriebsmodus durch Auswählen einer der folgenden Optionen:
Hohe Sicherheit ohne automatisches Failover (synchron)
In diesem Modus wird die Datenbank weiterhin synchronisiert, und manuelles Failover ist weiterhin möglich. Weitere Informationen finden Sie unter Synchrone Datenbankspiegelung (Modus für hohe Sicherheit).
Hohe Leistung (asynchron)
In diesem Modus kann es vorkommen, dass die Spiegeldatenbank leicht hinter die Prinzipaldatenbank zurückfällt; manuelles Failover ist nicht mehr möglich. Weitere Informationen finden Sie unter Asynchrone Datenbankspiegelung (Modus für hohe Leistung).
So ändern Sie den Betriebsmodus
Deaktivieren des automatischen Failovers mithilfe von Transact-SQL
Der Datenbankbesitzer kann jederzeit in einer Datenbank-Spiegelungssitzung das automatische Failover deaktivieren, indem er den Zeugen deaktiviert.
So deaktivieren Sie den Zeugen
Vorgehensweise: Entfernen des Zeugen aus einer Datenbank-Spiegelungssitzung (Transact-SQL)
HinweisWenn der Zeuge deaktiviert wird, während die Transaktionssicherheitsstufe FULL beibehalten wird, wird die Sitzung in den Modus für hohe Sicherheit mit automatischem Failover versetzt.