Bei der Spiegelung gibt es drei operative Modi:
Der synchrone Modus ist der Standard. Diese Modi steuern, wann und wie Transaktionen auf dem Spiegelserver aufgezeichnet werden. Sie werden mit der Serveroption -xp gesetzt.
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' ); |
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 betriebsbereiten Server in einem synchronisierten Status befinden und an den Spiegelserver gesendete Änderungen zuerst bestätigt werden müssen, bevor der Primärserver fortfahren kann.
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, ist es möglich, dass manche festgeschriebene Transaktionen verloren gehen, wenn der Spiegelserver übernimmt.
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 wird (trotz der Wahrscheinlichkeit, dass Transaktionen verloren gehen), setzen Sie mit der Serveroption -xp die Option "autofailover" auf "yes". 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.
Es wird empfohlen, dass Sie die Option -xp autofailover auf "yes" 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.
Die Option synchronize_mirror_on_commit ermöglicht es Ihnen zu steuern, wann es als sicher gilt, 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. Weitere Hinweise finden Sie unter Systemereignisse bei der Datenbankspiegelung.
Synchronisationsstatus
Statusinformationsdateien
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |