Datenbankspiegelungsmodi

Es gibt drei Betriebsmodi, die steuern, wann und wie Transaktionen auf dem Spiegelserver erfasst werden. In fast allen Fällen wird der Standardmodus "synchronous", empfohlen, weil er der zuverlässigste ist.

Bei der Datenbankspiegelung gibt es drei Betriebsmodi:

synchronous (Standardwert)
asynchronous
asyncfullpage

Diese Modi steuern, wann und wie Transaktionen auf dem Spiegelserver erfasst werden, und Sie legen sie fest, indem Sie mit der SET MIRROR OPTION-Anweisung den Wert der synchronization_mode-Option setzen.

Das Senden von Logseiten an die Kopieknoten erfolgt immer asynchron, unabhängig vom gewählten Modus.

Beim Wählen eines Synchronisationsmodus für Ihr Datenbankspiegelungssystem müssen Sie bestimmen, ob bei einem Failover die Performance von Änderungen an der Primärdatenbank oder das Vermeiden des Verlusts von Transaktionen wichtiger ist.

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

SELECT DB_PROPERTY( 'MirrorMode' );

Synchroner Modus (Standardeinstellung)

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 und Asynchron-Ganzseiten-Modus (nicht empfehlenswert)

Der asynchrone Modus und der Asynchron-Ganzseiten-Modus sind zwar schneller als der synchrone Modus, aber weniger zuverlässig. Standardmäßig gilt: Wenn der Primärserver unerwartet ausfällt, übernimmt der Spiegelserver nicht automatisch als Primärserver.

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. Diese Einstellung verringert das Verkehrsaufkommen zwischen den beiden Datenbankservern und verbessert die Performance des Primärservers. Wenn die aktuelle Logseite nicht innerhalb der im pagetimeout-Parameter 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.

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 Fehlerbehandlung: Wiederherstellung nach einem Primärserver-Ausfall.

Hinweis

Es wird empfohlen, die auto_failover-Spiegelungsoption auf ON zu setzen, wenn Sie den asynchronen oder den Asynchron-Ganzseiten-Modus verwenden. Dadurch übernimmt der Spiegelserver automatisch als Primärserver, wenn der Primärserver ausfällt. Die Verwendung der auto_failover-Option kann dazu führen, dass Transaktionen verloren gehen.

Die synchronize_mirror_on_commit-Datenbankoption steuert, wann im asynchronen oder Asynchron-Ganzseiten-Modus gewährleistet ist, dass Datenbankänderungen an einen Spiegelserver gesendet wurden. Wenn Sie diese Option auf "On" setzen, bewirkt jedes COMMIT, dass im Transaktionslog erfasste Änderungen an den Spiegelserver gesendet werden und dass eine Bestätigung vom Spiegelserver an den Primärserver gesendet wird, sobald die Änderungen vom Spiegelserver empfangen wurden. Diese Option kann mit SET TEMPORARY OPTION für bestimmte Transaktionen 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 Datenbankspiegelungssystem auftritt. Sie können diese Ereignisse z.B. zur Benachrichtigung des Administrators bei einem Failover verwenden.

Im Asynchron- oder Asynchron-Ganzseiten-Modus müssen Sie bestimmen, was geschieht, wenn ein Failover auftritt und Transaktionen nicht in der Datenbank festgeschrieben werden.

Ein Spiegelungssystem, das im asynchronen oder Asynchron-Ganzseiten-Modus (asyncfullpage) läuft, veranlasst den Primärserver weniger häufig zu Wartephasen als wenn der synchrone Modus verwendet wird. Jedoch auch im asynchronen oder asyncfullpage-Modus muss bei gesendeten Nachrichten vom Primärserver an den Spiegelserver auf eine Bestätigung vom Spiegelserver gewartet werden, wodurch sich Verzögerungen ergeben könnten. Außerdem ist das Senden von Paketen an den Spiegelserver mit einem geringen Overhead verbunden. Der asynchrone Modus und der Asynchron-Ganzseiten-Modus werden nicht empfohlen, da Transaktionen verloren gehen können.

Siehe auch

Synchronisationsstatus für Spiegelungssysteme

Kommentieren Sie diese Seite in DocCommentXchange.