Synchrone Datenbankspiegelung (Modus für hohe Sicherheit)

Wenn die Transaktionssicherheit auf FULL festgelegt ist, wird die Datenbank-Spiegelungssitzung im Modus für hohe Sicherheit und, nach einer Synchronisierungsphase zu Beginn, synchron ausgeführt. In diesem Thema werden die Details zu Datenbankspiegelungssitzungen beschrieben, die für eine synchrone Operation konfiguriert sind. In diesem Thema wird angenommen, dass Sie mit den grundlegenden Konzepten der Datenbank-Spiegelungsvorgänge vertraut sind. Weitere Informationen finden Sie unter Datenbank-Spiegelungssitzungen.

Um eine synchrone Operation für eine Sitzung zu erreichen, muss der Spiegelserver die Spiegeldatenbank mit der Prinzipaldatenbank synchronisieren. Wenn die Sitzung startet, beginnt der Prinzipalserver damit, sein aktives Protokoll an den Spiegelserver zu senden. Der Spiegelserver schreibt so schnell wie möglich alle eingehenden Protokolldatensätze auf den Datenträger. Sobald alle empfangenen Protokolldatensätze auf den Datenträger geschrieben wurden, werden die Datenbanken synchronisiert. Solange die Partner kommunizieren, verbleiben die Datenbanken synchronisiert.

Hinweis:
Verwenden Sie zum Überwachen von Statusänderungen in einer Datenbank-Spiegelungssitzung die Database Mirroring State Change-Ereignisklasse. Weitere Informationen finden Sie unter Database Mirroring State Change-Ereignisklasse.

Nach Abschluss der Synchronisierung wird für jede Transaktion, für die auf der Prinzipaldatenbank ein Commit ausgeführt wurde, auch auf dem Spiegelserver ein Commit ausgeführt, um den Schutz der Daten sicherzustellen. Dies wird erreicht, indem erst dann ein Commit für eine Transaktion auf der Prinzipaldatenbank ausgeführt wird, wenn der Prinzipalserver eine Meldung vom Spiegelserver empfängt, die besagt, dass das Protokoll der Transaktion festgeschrieben wurde. Beachten Sie, dass die Wartezeit für diese Meldung die Wartezeit für die Transaktion verlängert.

Die für die Synchronisierung benötigte Zeit hängt in hohem Maße davon ab, wie weit die Spiegeldatenbank zu Beginn der Sitzung gegenüber der Prinzipaldatenbank zurücklag (gemessen an der Anzahl der Protokolldatensätze, die anfänglich vom Prinzipalserver empfangen wurden), sowie von der Arbeitsauslastung auf der Prinzipaldatenbank und der Geschwindigkeit des Spiegelsystems. Nachdem eine Sitzung synchronisiert wurde, verbleibt das festgeschriebene Protokoll, das noch auf der Spiegeldatenbank wiederholt werden muss, in der Wiederholungswarteschlange. Weitere Informationen finden Sie unter Datenbank-Spiegelungssitzungen.

Sobald die Spiegeldatenbank synchronisiert ist, wird der Status beider Kopien der Datenbank in SYNCHRONIZED geändert.

Die synchrone Operation wird wie folgt beibehalten:

1. Der Prinzipalserver schreibt das Protokoll für die Transaktion in das Transaktionsprotokoll, sobald er eine Transaktion von einem Client erhält.
2. Der Prinzipalserver schreibt die Transaktion in die Datenbank und sendet gleichzeitig den Protokolldatensatz an den Spiegelserver. Der Prinzipalserver wartet auf eine Bestätigung vom Spiegelserver, bevor er dem Client eine der folgenden Aktionen bestätigt: einen Transaktionscommit oder ein Rollback.
3. Der Spiegelserver schreibt das Protokoll fest und gibt eine Bestätigung an den Prinzipalserver zurück.
4. Sobald er die Bestätigung vom Spiegelserver erhält, sendet der Prinzipalserver eine Bestätigungsmeldung an den Client.

Im Modus für hohe Sicherheit werden Ihre Daten dadurch geschützt, dass die an zwei Stellen vorhandenen Daten synchronisiert werden müssen. Es ist sichergestellt, dass alle Transaktionen, für die ein Commit ausgeführt wurde, auf dem Spiegelserver auf den Datenträger geschrieben werden.

Modus für hohe Sicherheit ohne automatisches Failover

Die folgende Abbildung veranschaulicht die Konfiguration des Modus für hohe Sicherheit ohne automatisches Failover. Die Konfiguration besteht nur aus den zwei Partnern.

Wenn die Partner verbunden sind und die Datenbank bereits synchronisiert ist, wird das manuelle Failover unterstützt. Wenn die Spiegelserverinstanz ausfällt, bleibt die Prinzipalserverinstanz in Betrieb und wird ungeschützt ausgeführt (d. h., ohne die Spiegelung der Daten). Wenn der Prinzipalserver ausfällt, wird die Spiegelung unterbrochen, der Dienst kann aber manuell auf dem Spiegelserver erzwungen werden (mit möglichem Datenverlust). Weitere Informationen finden Sie unter Erzwungener Dienst (mit möglichem Datenverlust).

Modus für hohe Sicherheit mit automatischem Failover

Automatisches Failover bietet eine hohe Verfügbarkeit, indem sichergestellt wird, dass die Datenbank trotz Ausfall eines Servers weiterhin bedient wird. Zur Unterstützung eines automatischen Failovers muss die Sitzung eine dritte Serverinstanz besitzen, den Zeugen, der sich idealerweise auf einem dritten Computer befindet. Die folgende Abbildung veranschaulicht die Konfiguration einer Sitzung im Modus für hohe Sicherheit mit automatischem Failover.

Im Gegensatz zu den beiden Partnern stellt der Zeuge die Datenbank nicht bereit. Der Zeuge unterstützt das automatische Failover einfach dadurch, dass er prüft, ob der Prinzipalserver aktiv und funktionsfähig ist. Der Spiegelserver initiiert das automatische Failover nur, wenn der Spiegel und der Zeuge miteinander verbunden bleiben, nachdem beide vom Prinzipalserver getrennt wurden.

Wenn ein Zeuge festgelegt ist, benötigt die Sitzung das Quorum – eine Beziehung zwischen mindestens zwei Serverinstanzen, damit die Datenbank verfügbar gemacht werden kann. Weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit und Automatisches Failover. Weitere Informationen finden Sie unter Datenbank-Spiegelungszeuge.

Für automatisches Failover müssen folgende Bedingungen erfüllt sein:

• Die Datenbank ist bereits synchronisiert.
• Der Fehler tritt auf, während alle drei Serverinstanzen verbunden sind und der Zeugenserver und der Spiegelserver verbunden bleiben.

Der Verlust eines Partners hat folgenden Effekt:

• Wenn der Prinzipalserver unter den oben aufgeführten Bedingungen ausfällt, findet ein automatisches Failover statt. Der Spiegelserver wechselt in die Rolle des Prinzipals und bietet seine Datenbank als Prinzipaldatenbank an.
• Wenn der Prinzipalserver ausfällt, da diese Bedingungen nicht erfüllt sind, kann die Ausführung des Dienstes (mit möglichem Datenverlust) gegebenenfalls erzwungen werden. Weitere Informationen finden Sie unter Erzwungener Dienst (mit möglichem Datenverlust).
• Wenn nur der Spiegelserver nicht mehr verfügbar ist, setzen der Prinzipal und der Zeuge ihren Betrieb fort.

Wenn die Sitzung ihren Zeugen verliert, sind für das Quorum beide Partner erforderlich. Wenn einer der Partner das Quorum verliert, verlieren beide Partner das Quorum, und die Datenbank ist erst dann wieder verfügbar, wenn das Quorum erneut hergestellt worden ist. Durch diese Quorumanforderung wird sichergestellt, dass die Datenbank in Abwesenheit eines Zeugen niemals ungeschützt (d. h., ohne gespiegelt zu werden) ausgeführt wird.

Hinweis:
Wenn zu erwarten ist, dass der Zeuge für einen signifikanten Zeitraum getrennt bleiben wird, sollten Sie den Zeugen vorübergehend aus der Sitzung entfernen, bis er wieder verfügbar ist.

Siehe auch

Konzepte

Datenbank-Spiegelungssitzungen
Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit
Transact-SQL-Einstellungen und Datenbankspiegelungs-Betriebsmodi

Andere Ressourcen

Überwachen der Datenbankspiegelung

Hilfe und Informationen

Informationsquellen für SQL Server 2005