Datenbankspiegelung erfordert eine getrennte Lizenz. Weitere Hinweise finden Sie unter Getrennt lizenzierbare Komponenten.
Die Datenbankspiegelung ist eine Konfiguration aus zwei oder drei auf getrennten Computern laufenden Datenbankservern, die zusammenarbeiten, um Kopien der Datenbank- und Transaktionslogdateien zu führen.
Der Primärserver und der Spiegelserver führen jeweils eine Kopie der Datenbankdateien und der Transaktionslogdateien, während der dritte Server, Arbiterserver genannt, ggf. verwendet wird, um zu bestimmen, welcher der beiden anderen Server Eigentümer der Datenbank wird. Der Arbiterserver führt keine Kopie der Datenbank. Die Konfiguration der drei Datenbankserver (Primär-, Spiegel- und Arbiterserver) wird Spiegelsystem genannt, und der Primär- und der Spiegelserver werden gemeinsam die betriebsbereiten Server oder Partner genannt.
Clients verbinden sich mit dem Primärserver, um auf die Datenbank zuzugreifen. Alle in der Datenbank gemachten Änderungen werden im Transaktionslog auf dem Primärserver aufgezeichnet. Wenn die Änderungen festgeschrieben werden, sendet der Primärserver die Transaktionslogseiten an den Spiegelserver, wo sie an einer Kopie (Spiegel) der Datenbank angewendet werden. Auf die Kopie der Datenbank auf dem Spiegelserver kann nur im schreibgeschützten Modus zugegriffen werden, während dieser Datenbankserver als Spiegelserver verwendet wird. Weitere Hinweise finden Sie unter Schreibgeschützten Zugriff auf eine Datenbank konfigurieren, die auf dem Spiegelserver läuft.
Wenn der Primärserver aufgrund eines Hardware- oder Softwarefehlers ausfällt, verhandelt der Spiegelserver mit dem Arbiterserver, um Eigentümer der Datenbank zu werden und die Rolle des Primärservers zu übernehmen. Damit die Übertragung der Eigentümerschaft oder ein Rollenwechsel stattfinden kann, müssen der weiterhin betriebsbereite Server und der Arbiterserver übereinstimmen, dass der Spiegelserver in einem aktuellen, synchronisierten Status zu dem Zeitpunkt ist, an dem der Rollenwechsel versucht wird. Die Verbindungen der Clients zum ursprünglichen Primärserver werden getrennt, wobei alle nicht festgeschriebenen Transaktionen verloren gehen. Clients müssen sich daher erneut mit der Datenbank auf dem neuen Primärserver verbinden, um weiterhin auf die Datenbank zugreifen zu können. Wenn der ursprüngliche Primärserver wieder verfügbar wird, nimmt er die Rolle des Spiegelservers an.
Die Datenbankserver zeigen beim Start Statusmeldungen im Meldungsfenster des Datenbankservers an, die angeben, welche Rolle der Server annimmt und wie weit er im Startprozess vorangekommen ist. Eine Meldung wird angezeigt, wenn die Datenbank neu gestartet werden muss, weil ein oder mehrere Server im Spiegelsystem ausfallen oder weil ein Server die Rolle von Spiegel- auf Primärserver wechselt.
Wenn ein Assertierungsfehler bei einem Server auftritt, der Teil eines Spiegelsystems ist, gibt der Server einen Fehler in die Meldungslogdatei des Datenbankservers aus und beendet anschließend. Dies benachrichtigt die anderen Server von seinem Ausfall, damit sie die entsprechende Aktion durchführen können.
Bei der Datenbankspiegelung gibt es keine besonderen Hardware- oder Software-Anforderungen, und die Datenbankserver können an örtlich verschiedenen Standorten ausgeführt werden. Datenbankserver, die an einem Datenbank-Spiegelungssystem teilnehmen, können gespiegelte wie auch ungespiegelte Datenbanken ausführen. Überdies kann der Arbiterserver der Arbiter bei mehreren Datenbank-Spiegelungssystemen sein.
Details über den Status der einzelnen Datenbanken im Datenbank-Spiegelungssystem werden in einer Statusinformationsdatei gespeichert. Weitere Hinweise finden Sie unter Statusinformationsdateien.
Die Datenbankspiegelung ist kein Ersatz für einen Sicherungs- und Wiederherstellungsplan. Sie sollten immer eine Sicherungs- und Wiederherstellungsstrategie bei Ihrer Datenbank implementieren. Weitere Hinweise finden Sie unter Datenbankspiegelung und Sicherungen und Daten sichern und wiederherstellen.
Informationen zum Upgrade von SQL Anywhere und zum Neuaufbau einer Datenbank, die zu einem Datenbank-Spiegelungssystem gehört, finden Sie unter Upgrade von SQL Anywhere-Software und -Datenbanken in einem Datenbank.
Bevor ein Server die Rolle eines Primärservers annehmen kann, muss er ein Quorum erhalten, d.h. dass zumindest ein weiterer Server zustimmen muss, dass der Server Datenbankeigentümer sein kann. Wenn der Spiegelserver ausfällt, während der Primär- und der Arbiterserver verbunden sind, gewährt der Primärserver weiter Zugriff auf die Datenbank. Wenn der Primärserver das Quorum verliert, ist er nicht mehr in der Lage, Zugriff auf die Datenbank zu ermöglichen. Wenn das passiert, stoppt er die gespiegelte Datenbank und versucht, sie neu zu starten. Anschließend wartet er auf den Erhalt des Quorums, bevor er die Datenbank verfügbar macht.
Wenn Sie ein Datenbank-Spiegelungssystem starten, durchlaufen die Datenbankserver einen Startprozess, um das Quorum zu erreichen und Clientverbindungen zu akzeptieren. Die folgenden Schritte beschreiben eine typische Ereignissequenz bei diesem Prozess:
Der Arbiter wartet auf Server 1 und Server 2.
Server 1 sucht nach dem Ariter-Server oder Server 2.
Server 1 verbindet sich mit dem Arbiterserver.
Server 1 verhandelt mit dem Arbiterserver, um Primärserver zu werden.
Der Arbiterserver und Server 1 kommen überein, dass Server 1 der Primärserver werden kann.
Server 1 beginnt, Verbindungen zu akzeptieren.
Server 2 sucht nach Server1 und dem Arbiterserver.
Server 2 verbindet sich mit dem Arbiterserver und mit Server 1.
Server 2 verlangt nach einem Quorum. Er erhält kein Quorum, weil Server 1 der Primärserver ist, und so geht er in Bereitschaft, auf Transaktionen von Server 1 zu warten.
Server 1 sendet Transaktionen an Server 2.
Bei der Verwendung der Datenbankspiegelung gelten folgende Einschränkungen:
Netzwerk-Datenbankserver erforderlich Da eine Spiegelung Netzwerkkommunikation zwischen den Datenbankservern beinhaltet, müssen Sie den Netzwerk-Datenbankserver (dbsrv11) verwenden. Der Personal Server kann nicht verwendet werden.
LOAD TABLE-Anweisung Wenn Sie eine LOAD TABLE-Anweisung mit einer Basistabelle ausführen, müssen Sie entweder WITH ROW LOGGING oder WITH CONTENT LOGGING als Protokollierungsstufe für die Anweisung angeben. Diese Klauseln ermöglichen es, dass die geladenen Daten im Transaktionslog aufgezeichnet werden, damit sie auch in die Spiegeldatenbank geladen werden können. Wenn diese Klauseln nicht angegeben werden, wird ein Fehler gemeldet. Weitere Hinweise finden Sie unter LOAD TABLE-Anweisung und Daten mit der LOAD TABLE-Anweisung importieren.
TCP/IP erforderlich Nur TCP/IP-Verbindungen sind zwischen gespiegelten Servern zulässig.
Failover und geplante Ereignisse Wenn Ihre Datenbank geplante Ereignisse hat und ein Failover auftritt, laufen geplante Ereignisse auf dem Spiegelserver, solange der Failover vor der geplanten Startzeit für das Ereignis beendet ist. Ansonsten wird das nächste geplante Ereignis auf dem Spiegelserver ausgeführt.
Transaktionslog-Einschränkungen Sie können das Transaktionslog nicht kürzen, wenn Sie Datenbankspiegelung verwenden, weil dies zu verlorenen Transaktionen führen kann. Sie können das Transaktionslog so oft wie nötig umbenennen. Wenn Sie alte Transaktionslogs entfernen möchten, können Sie ein geplantes Ereignis verwenden, um sie zu löschen, sofern Sie sicher sind, sie nicht mehr zu benötigen. Sie können z.B. ein Ereignis erstellen, dass täglich ausgeführt wird und Kopien des Transaktionslogs löscht, die älter als eine Woche sind. Weitere Hinweise finden Sie unter Datenbankspiegelung und Transaktionslogdateien.
Webserver können nicht an einem Spiegelungssystem teilnehmen Sie können einen SQL Anywhere-Datenbankserver nicht als Webserver verwenden, wenn der Datenbankserver an einem Spiegelungssystem teilnimmt, da sich bei einem Failover-Mechanismus die IP-Adresse des Datenbankservers ändert.
Wenn Sie die Datenbankspiegelung verwenden, sollten Anwendungen in fast allen Fällen in der Lage sein, auf dieselbe Weise auszuführen, wie sie es bei einer ungespiegelten Datenbank tun. Es gibt allerdings ein paar Überlegungen, die zu berücksichtigen sind, wenn Sie Anwendungen zur Verwendung mit einer Datenbankspiegelung entwickeln:
Erstellen Sie Clients, die sich mit der Datenbank erneut verbinden können (z.B. muss der Benutzer möglicherweise bei einem Failover die Anwendung herunterfahren und neu starten).
Wenn die Datenspiegelung im Asynchron- oder Asynchron-Ganzseiten-Modus ausgeführt wird, müssen Sie festlegen, was geschieht, wenn ein Failover auftritt und Transaktionen nicht in der Datenbank festgeschrieben werden.
Unvollständige Transaktionen müssen zurückgesetzt werden, wenn der Spiegelserver Eigentümer der Datenbank wird, und je länger eine Transaktion ist, desto länger braucht es, sie zurückzusetzen. Die Wiederherstellungsgeschwindigkeit bei einem Failover hängt von der Anzahl der Clients und von der Dauer ihrer Transaktionen ab, die zurückgesetzt werden müssen. Wenn die Wiederherstellungsgeschwindigkeit wichtig ist, sollten Sie Ihre Anwendung so planen, dass sie, wo immer möglich, kurze Transaktionen verwendet.
Hinweise zum Upgrade von SQL Anywhere für ein Datenbank-Spiegelungssystem, einschließlich der Anwendung von EBFs, finden Sie unter Upgrade von SQL Anywhere-Software und -Datenbanken in einem Datenbank.
Vorteile der Datenbankspiegelung
Zur Rolle des Arbiterservers
Modus der Datenbankspiegelung wählen
| 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 |