Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Failover eines Multi-AZ-DB-Clusters für Amazon RDS
Bei einem geplanten oder ungeplanten Ausfall Ihrer Writer-DB-Instance in einem Multi-AZ-DB-Cluster führt Amazon RDS automatisch einen Failover auf eine Reader-DB-Instance in einer anderen Availability Zone durch. Dies gewährleistet eine hohe Verfügbarkeit bei minimalen Unterbrechungen. Failovers können bei Hardwarefehlern, Netzwerkproblemen oder manuellen Anfragen auftreten. In diesem Thema werden die automatische Erkennung von Ausfällen, die Reihenfolge der Ereignisse während eines Failovers und deren Auswirkungen auf Lese- und Schreibvorgänge beschrieben. Außerdem werden bewährte Methoden zur Überwachung und Minimierung von Failover-Zeiten vorgestellt.
Die Zeit bis zum Abschluss des Failovers hängt von der Datenbankaktivität und anderen Bedingungen ab, wenn die Writer-DB-Instance nicht verfügbar war. Der Failover-Prozess dauert normalerweise unter 35 Sekunden. Das Failover wird abgeschlossen, wenn beide Reader-DB-Instances ausstehende Transaktionen vom fehlgeschlagenen Schreiber angewendet haben. Wenn der Failover abgeschlossen ist, kann es länger dauern, bis die RDS Konsole die neue Availability Zone wiedergibt.
Themen
Automatische Failover
Amazon RDS wickelt Failovers automatisch ab, sodass Sie den Datenbankbetrieb so schnell wie möglich ohne administrativen Eingriff wieder aufnehmen können. Zum Ausfall wechselt die Writer-DB-Instance automatisch zu einer Reader-DB-Instance.
Manuelles Versagen über einen Multi-AZ-DB-Cluster
Wenn Sie ein manuelles Failover für einen Multi-AZ-DB-Cluster durchführen, wird RDS zunächst die primäre DB-Instance beendet. Anschließend erkennt das interne Überwachungssystem, dass die primäre DB-Instance fehlerhaft ist, und stellt eine lesbare Replikat-DB-Instance zur Verfügung. Der Failover-Prozess dauert normalerweise unter 35 Sekunden.
Sie können ein Failover eines Multi-AZ-DB-Clusters manuell durchführen, indem Sie den AWS Management Console, oder den AWS CLI verwenden. RDS API
Manuelles Ausfallen eines Multi-AZ-DB-Clusters
Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Datenbanken aus.
-
Wählen Sie den Multi-AZ-DB-Cluster aus, den Sie ausfallen möchten.
-
Wählen Sie für Aktionen die Option Failover aus.
Die Seite für den Failover-DB-Cluster wird angezeigt.
-
Wählen Sie Failover, um das manuelle Failover zu bestätigen.
Verwenden Sie den Befehl, um ein manuelles Failover eines Multi-AZ-DB-Clusters durchzuführen. AWS CLI failover-db-cluster
aws rds failover-db-cluster --db-cluster-identifiermymultiazdbcluster
Um ein manuelles Failover eines Multi-AZ-DB-Clusters durchzuführen, rufen Sie Amazon RDS API F auf ailoverDBCluster und geben Sie den DBClusterIdentifier an.
Ermitteln, ob ein Multi-AZ-DB-Cluster ausgefallen ist
Um festzustellen, ob Ihr Multi-AZ-DB-Cluster erfolgreich ausgeführt wurde, können Sie Folgendes tun:
Richten Sie DB-Event-Abonnements ein, um Sie per E-Mail oder darüber zu informierenSMS, dass ein Failover eingeleitet wurde. Weitere Informationen über -Ereignisse finden Sie unter Mit RDS Amazon-Event-Benachrichtigungen arbeiten.
Zeigen Sie Ihre DB-Ereignisse mithilfe der RDS Amazon-Konsole oder mithilfe von API Operations an.
Zeigen Sie den aktuellen Status Ihres Multi-AZ-DB-Clusters mithilfe der RDS Amazon-Konsole AWS CLI, der und der RDS API an.
Informationen darüber, wie Sie auf Failover reagieren, die Wiederherstellungszeit verkürzen können, und weitere bewährte Methoden für Amazon RDS finden Sie unterBewährte Methoden für Amazon RDS.
Einstellung der JVM TTL für DNS Namenssuchvorgänge
Der Failover-Mechanismus ändert den Domain Name System (DNS) -Datensatz der DB-Instance automatisch so, dass er auf die Reader-DB-Instance verweist. Als Ergebnis müssen alle bestehenden Verbindungen zu Ihrer DB-Instance neu hergestellt werden. In einer Java-Virtual-Machine-Umgebung (JVM) müssen Sie aufgrund der Funktionsweise des DNS Java-Caching-Mechanismus möglicherweise die Einstellungen neu JVM konfigurieren.
Die Namen der JVM Caches suchen DNS nach Namen. Wenn der einen Hostnamen in eine IP-Adresse JVM auflöst, speichert er die IP-Adresse für einen bestimmten Zeitraum im Cache, der als () bezeichnet wird. time-to-liveTTL
Da AWS Ressourcen DNS Namenseinträge verwenden, die sich gelegentlich ändern, empfehlen wir, dass Sie Ihren JVM mit einem TTL Wert von nicht mehr als 60 Sekunden konfigurieren. Dadurch wird sichergestellt, dass Ihre Anwendung, wenn sich die IP-Adresse einer Ressource ändert, die neue IP-Adresse der Ressource empfangen und verwenden kann, indem sie die erneut abfragt. DNS
Bei einigen Java-Konfigurationen TTL ist die JVM Standardeinstellung so eingestellt, dass DNS Einträge erst aktualisiert werden, wenn der JVM neu gestartet wird. Wenn sich also die IP-Adresse für eine AWS Ressource ändert, während Ihre Anwendung noch läuft, kann sie diese Ressource erst verwenden, wenn Sie die manuell neu starten JVM und die zwischengespeicherten IP-Informationen aktualisiert werden. In diesem Fall ist es wichtig, die JVM s TTL so einzustellen, dass die zwischengespeicherten IP-Informationen regelmäßig aktualisiert werden.
Anmerkung
Die Standardeinstellung TTL kann je nach Ihrer Version JVM und je nachdem, ob ein Sicherheitsmanager installiert ist, variieren. Viele JVMs bieten eine Standardeinstellung von TTL weniger als 60 Sekunden. Wenn Sie einen solchen JVM und keinen Sicherheitsmanager verwenden, können Sie den Rest dieses Themas ignorieren. Weitere Informationen zu Sicherheits-Managern in Oracle finden Sie unter The Security Manager
Um die JVM s zu ändernTTL, legen Sie den networkaddress.cache.ttl
-
Um den Eigenschaftswert global für alle Anwendungen festzulegenJVM, die den
networkaddress.cache.ttlin der$JAVA_HOME/jre/lib/security/java.securityDatei festgelegten Wert verwenden.networkaddress.cache.ttl=60 -
Um die Eigenschaft nur für Ihre Anwendung lokal festzulegen, legen Sie
networkaddress.cache.ttlim Initialisierungscode Ihrer Anwendung fest, bevor Netzwerkverbindungen hergestellt werden.java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
