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

SQL Anywhere 12.0.1 (Deutsch) » SQL Anywhere Server - Datenbankadministration » Datenbankwartung » SQL Anywhere-Hochverfügbarkeitsoption » Konfiguration eines Datenbankspiegelungssystems

 

Szenarien für das Unterbrechen von Verbindungen in einem Datenbankspiegelungssystem

Wenn in einem Datenbankspiegelungssystem Verbindungen zwischen Datenbankservern unterbrochen werden, gelten folgende Hinweise:

  • Die Zeit, die ein Server benötigt, um die Unterbrechung einer Netzwerkverbindung zu erkennen, hängt von folgenden Faktoren ab:

    1. Art der Unterbrechung der Verbindung. Wenn ein Netzwerkkabel am Computer abgezogen wird, erkennen einige Betriebssysteme dieses Problem sofort und unterbrechen somit die logische Verbindung. Wenn das Problem auf einen Fehler in einem Netzwerkgerät zurückzuführen ist, wird das Problem vom Server wahrscheinlich weniger rasch erkannt.

    2. Einstellung der Verfügbarkeitszeitüberschreitung in der Spiegelserver-Verbindungszeichenfolge. Siehe LivenessTimeout-Verbindungseigenschaft.

  • Damit der Primärserver die Eigentümerschaft einer gespiegelten Datenbank behält, muss er mit mindestens einem der anderen Server (Spiegel- oder Arbiterserver) verbunden sein. Wenn Verbindungen zu den beiden anderen Servern verlorengehen, wird die Datenbank neu gestartet und der Primärserver wartet, bis er mindestens eine dieser Verbindungen wiederherstellen kann, um ihren Status zu überprüfen.

  • Die Verbindungen zwischen Servern werden automatisch wieder aufgenommen, wenn das Problem, das eine Unterbrechung der Verbindung verursacht, behoben ist.

  • Bis ein Server eine Unterbrechung der Verbindung erkennt, behält er die Rolle, die ihm zuvor zugeordnet wurde. Dieses Verhalten kann dazu führen, dass zwei Server versuchen, kurze Zeit als Primärserver zu agieren, wenn der Server, der zuvor der Spiegelserver war, eine unterbrochene Verbindung mit dem Primärserver erkennt, bevor der Primärserver feststellt, dass seine Verbindung mit dem Spiegelserver unterbrochen wurde. Die erste Aktualisierung auf dem ursprünglichen Primärserver blockiert, wenn der Server versucht, die Änderungen an den anderen Server zu senden, sodass das Potenzial für einen Verlust von Transaktionen begrenzt wird, wenn diese Situation eintreten sollte.

    Wenn der ursprüngliche Primärserver die unterbrochene Verbindung mit dem ursprünglichen Spiegelserver erkennt und den Arbiter-Status ermittelt, stellt er fest, dass ein Failover aufgetreten ist, und startet die Datenbank neu.

  • Wenn ein als Spiegelserver agierender Server seine Datenbank neu starten muss, wird der Zugriff auf die Datenbank auf diesem Server blockiert, bis eine Verbindung mit dem Primärserver wiederaufgenommen wurde.

  • Netzwerkausfälle können sich, abhängig von der Topologie des Netzwerks, auf Client- und Spiegelserververbindungen auswirken.

Die folgenden Szenarien fördern das Verständnis darüber, was vorgeht, wenn in einem Spiegelungssystem Verbindungen ausfallen. Diese Szenarien verwenden die folgende Datenbank-Spiegelungskonfiguration, die aus Server 1, Server 2 und einem Arbiterserver besteht, die im synchronen Modus ausgeführt werden:

Ein Beispiels-Datenbankspiegelungssystem, das aus Server 1, Server 2 und einem Arbiterserver besteht.

Sie können jederzeit die Datenbankeigenschaften MirrorState, PartnerState und ArbiterState verwenden, um den Status der Datenbankserver im Spiegelungssystem zu bestimmen. Siehe MirrorState-Datenbankeigenschaft, PartnerState-Datenbankeigenschaft und ArbiterState-Datenbankeigenschaft.

 Szenario 7: Verbindung zwischen dem Primärserver und dem Arbiterserver ist getrennt
 Szenario 8: Verbindung zwischen dem Spiegelserver und dem Arbiterserver ist getrennt
 Szenario 9: Verbindung zwischen dem Primärserver und dem Spiegelserver ist getrennt
 Szenario 10: Verbindung vom Primärserver zum Spiegelserver und Arbiterserver ist getrennt
 Szenario 11: Verbindung vom Spiegelserver zum Primärserver und zum Arbiterserver ist getrennt
 Szenario 12: Verbindungen vom Arbiterserver zum Primär- und Spiegelserver sind getrennt
 Szenario 13: Verbindungen zwischen allen Servern sind getrennt