Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SAP Sybase SQL Anywhere 16.0 (Deutsch) » SQL Anywhere Server - Datenbankadministration » Hochverfügbarkeit und Scale-Out-Systeme mit Schreibschutz » Datenbankspiegelung » Datenbankspiegelungssysteme verwalten

 

Rollentausch (Failover) in der Datenbankspiegelung

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 der Wechsel des Eigentümers oder Rollentausch stattfinden kann, müssen der weiterhin betriebsbereite Partnerserver und der Arbiter darin übereinstimmen, dass der Spiegelserver zu dem Zeitpunkt, zu dem der Rollentausch versucht wird, auf dem aktuellen Stand und im Status "synchronized" war.

  • Verbindungen von Clients mit dem 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.

  • Verbindungen von Clients mit der ursprünglichen Spiegeldatenbank bleiben bestehen, wenn ein Failover auftritt und der Spiegelserver zum Primärserver wird. Nach dem Failover können diese Clientverbindungen Änderungen an der Datenbank vornehmen.

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 Spiegelungssystem ausfallen oder weil ein Server die Rolle von Spiegel- auf Primärserver wechselt.

Wenn ein Assertierungsfehler bei einem Server auftritt, der Teil eines Spiegelungssystems 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.

Wenn eine Datenbank in einer Hochverfügbarkeitsumgebung auf ein Problem stößt, z.B. auf ein inkompatibles oder nicht übereinstimmendes Transaktionslog, wird sie gestoppt. Der Datenbankserver, auf dem die von dem Problem betroffene Datenbank läuft, wird ebenfalls heruntergefahren, es sei denn, auf ihm werden weitere Datenbanken ausgeführt.

Details über den Status der einzelnen Datenbanken im Datenbankspiegelungssystem werden in einer Statusinformationsdatei gespeichert.

  • Wenn ein Arbiterserver verwendet wird, erfolgt der Failover (Ausfallsicherung) vom Primär- zum Spiegelserver automatisch. Wenn Sie im synchronen Modus ausführen, gehen während des Failovers keine festgeschriebenen Transaktionen verloren.

  • Der Failover geht sehr schnell, da der Spiegelserver das Transaktionslog bereits angewendet hat. Wenn der Spiegelserver feststellt, dass der Primärserver ausgefallen ist, setzt er nicht-festgeschriebene Transaktionen zurück und macht anschließend die Datenbank verfügbar.

Wenn der Primärserver ausfällt, während er sich im Status "Synchronisation läuft" befindet, kann der Spiegelserver nicht als Primärserver übernehmen. Das Spiegelungssystem wartet darauf, dass der Primärserver wieder verfügbar 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.

 Siehe auch

Benutzerinitiierter Rollentausch (Failover)
Verwendung von Datenbankspiegelungssystem-Ereignissen zum Senden von Benachrichtigungs-E-Mails bei Failover