Modus der Datenbankspiegelung wählen

Bei der Datenbankspiegelung gibt es drei Betriebsmodi:

synchron
asynchron
Asynchron-Ganzseiten

Diese Modi steuern, wann und wie Transaktionen auf dem Spiegelserver aufgezeichnet werden, und Sie setzen diese mit der SET MIRROR OPTION-Anweisung, um den Wert der synchronization_mode-Option festzulegen. Der synchrone Modus ist der Standard.

Wenn Sie einen Synchronisationsmodus für Ihr Datenbank-Spiegelungssystem wählen, müssen Sie bestimmen, ob bei einem Failover die Wiederherstellungsgeschwindigkeit oder der Zustand der Daten wichtiger ist.

Sie können den Datenbankspiegelungsmodus überprüfen, indem Sie den Wert der Datenbankeigenschaft MirrorMode abfragen.

SELECT DB_PROPERTY( 'MirrorMode' );

Synchroner Modus

Im synchronen Modus werden festgeschriebene Transaktionen auf dem Spiegelserver garantiert aufgezeichnet. Sollte ein Fehler auf dem Primärserver auftreten, gehen nicht-festgeschriebene Transaktionen verloren, wenn der Spiegelserver übernimmt. In diesem Modus sendet der Primärserver Transaktionslogseiten an den Spiegel, wenn eine Transaktion festgeschrieben wird. Der Spiegelserver bestätigt die Übertragung, wenn er diese Seiten in seine Kopie des Transaktionslogs geschrieben hat. Der Primärserver antwortet der Anwendung erst, wenn er diese Bestätigung erhalten hat.

Die Verwendung des synchronen Modus bietet Transaktionssicherheit, weil sich die Partnerserver in einem synchronisierten Status befinden und an den Spiegelserver gesendete Änderungen zuerst bestätigt werden müssen, bevor der Primärserver fortfahren kann.

Asynchroner Modus

Im asynchronen Modus werden festgeschriebene Transaktionen auf dem Spiegelserver nicht garantiert aufgezeichnet. In diesem Modus sendet der Primärserver Transaktionslogseiten an den Spiegel, wenn eine Transaktion festgeschrieben wird. Er wartet nicht auf eine Bestätigung vom Spiegelserver, bevor er der Anwendung mitteilt, dass der COMMIT abgeschlossen wurde. Sollte ein Fehler auf dem Primärserver auftreten, können einige festgeschriebene Transaktionen verloren gehen, wenn der Spiegelserver übernimmt.

Asynchron-Ganzseiten-Modus

Im Asynchron-Ganzseiten-Modus (oder Seitenmodus) werden Seiten nicht bei einem COMMIT gesendet, sondern sie werden übermittelt, wenn die Seite voll ist. Dies verringert das Datenaufkommen zwischen den beiden Datenbankservern und verbessert die Performance des Primärservers. Wenn die aktuelle Logseite nicht innerhalb der im Parameter 'pagetimeout' angegebenen Anzahl von Sekunden an den Spiegelserver gesendet wurde, wird sie gesendet, auch wenn sie noch nicht voll ist. Der Standardwert für 'pagetimeout' ist 5 Sekunden. Dieser Modus beschränkt die Zeitspanne, in der festgeschriebene Transaktionen verloren gehen können, wenn der Primärserver ausfällt und der Spiegelserver Eigentümer der Datenbank wird. Der Asynchron-Ganzseiten-Modus impliziert einen asynchronen Vorgang, daher wartet der Primärserver nicht auf eine Bestätigung vom Spiegelserver.

Der asynchrone Modus und der Asynchron-Ganzseiten-Modus sind schneller als der synchrone Modus, aber aus den oben genannten Gründen weniger zuverlässig. Im asynchronen oder Asynchron-Ganzseiten-Modus ist der Failover vom Primärserver zum Spiegelserver nicht automatisch, weil der Spiegelserver möglicherweise nicht alle festgeschriebenen Transaktionen enthält, die am Primärserver angewendet wurden. Aus diesem Grund kann ein Spiegelserver beim Ausfall des Primärservers nicht standardmäßig Eigentümer einer Datenbank werden, wenn einer der beiden asynchronen Modi verwendet wird. Wenn in dieser Situation ein automatischer Failover erwünscht ist (trotz der Wahrscheinlichkeit, dass Transaktionen verloren gehen), setzen Sie mithilfe der SET MIRROR OPTION-Anweisung die Option "auto_failover" auf "on". Anderenfalls erkennt der ausgefallene Server beim Neustart, ob Transaktionen verloren gegangen sind. Wenn Transaktionen verloren gegangen sind, schreibt er eine Meldung an das Datenbankserver-Meldungslog und fährt die Datenbank herunter. Die aktuelle Datenbank und das Transaktionslog müssen dann durch eine Sicherungskopie ersetzt werden, bevor die Spiegelung fortgesetzt werden kann.

Hinweise, wie Sie einen Server nach einem Ausfall im asynchronen oder Asynchron-Ganzseiten-Modus wiederherstellen finden Sie unter Wiederherstellen nach einem Primärserver-Ausfall.

Hinweis

Es wird empfohlen, dass Sie die Spiegelungsoption für "auto_failover" auf "on" setzen, wenn Sie den asynchronen oder den Asynchron-Ganzseiten-Modus verwenden. Dadurch übernimmt der Spiegelserver automatisch als Primärserver, wenn der ursprüngliche Primärserver ausfällt.

Mit der Datenbankoption synchronize_mirror_on_commit können Sie steuern, wann es als sicher gelten soll, dass Datenbankänderungen an einen Spiegelserver gesendet wurden, der im asynchronen oder Asynchron-Ganzseiten-Modus ausgeführt wird. Wenn Sie diese Option auf "On" setzen, bewirkt jedes COMMIT, dass jede im Transaktionslog aufgezeichnete Änderung an den Spiegelserver gesendet wird, und dass eine Bestätigung vom Spiegelserver an den Primärserver gesendet wird, sobald die Änderungen auf dem Spiegelserver empfangen wurden. Diese Option kann bei bestimmten Transaktionen unter Verwendung von SET TEMPORARY OPTION gesetzt werden. Es kann auch nützlich sein, die Option bei bestimmten Anwendungen zu verwenden, indem die APPINFO-Zeichenfolge in einer Login-Prozedur untersucht wird.

SQL Anywhere unterstützt Systemereignisse, die unabhängig vom verwendeten Modus ausgelöst werden, wenn ein Failover in einem Datenbank-Spiegelungssystem auftritt. Sie können diese Ereignisse z.B. zur Benachrichtigung des Administrators bei einem Failover verwenden. Siehe Systemereignisse bei der Datenbankspiegelung.

Siehe auch

Synchronisationsstatus
Statusinformationsdateien

Kommentieren Sie diese Seite in DocCommentXchange.