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
Wenn es einen geplanten oder ungeplanten Ausfall Ihrer Writer-DB-Instance in einem Multi-AZ-DB-Cluster gibt, führt Amazon RDS automatisch ein Failover auf eine Reader-DB-Instance in einer anderen Availability Zone durch. Hierdurch wird eine hohe Verfügbarkeit mit minimaler Unterbrechung gewährleistet. Failovers können bei Hardwarefehlern, Netzwerkproblemen oder manuellen Anfragen auftreten. In diesem Thema werden die automatische Erkennung von Fehlern, 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 erläutert.
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 eigentliche Failover-Prozess abgeschlossen ist, kann es noch einmal etwas dauern, bis die RDS-Konsole die Daten für die neue Availability Zone geladen hat.
Themen
Automatische Failover
Amazon RDS führt den Failover-Prozess automatisch durch, sodass der Datenbankbetrieb so schnell wie möglich und ohne Verwaltungseingriff wieder aufgenommen werden kann. Zum Ausfall wechselt die Writer-DB-Instance automatisch zu einer Reader-DB-Instance.
Manuelles Versagen über einen Multi-AZ-DB-Cluster
Wenn Sie für einen Multi-AZ-DB-Cluster einen manuellen Failover erstellen, beendet RDS zunächst die primäre DB-Instance. Anschließend erkennt das interne Überwachungssystem, dass die primäre DB-Instance fehlerhaft ist, und stuft eine lesbare Replikat-DB-Instance hoch. Der Failover-Prozess dauert normalerweise unter 35 Sekunden.
Sie können für einen Multi-AZ-DB-Cluster manuell mit der AWS Management Console, AWS CLI oder RDS-API einen Failover erstellen.
Manuelles Ausfallen eines Multi-AZ-DB-Clusters
Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Databases (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 Failover-DB-Cluster wird angezeigt.
-
Wählen Sie Failover, um das manuelle Failover zu bestätigen.
Verwenden Sie zum manuellen Failover eines Multi-AZ-DB-Clusters den AWS CLI-Befehl failover-db-cluster.
aws rds failover-db-cluster --db-cluster-identifiermymultiazdbcluster
Um ein manuelles Failover eines Multi-AZ-DB-Clusters durchzuführen, rufen Sie die Amazon-RDS-API FailoverDBCluster auf und geben Sie die 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:
Sie können Benachrichtigungen per E-Mail oder per SMS für DB-Ereignisse abonnieren, bei denen ein Failover ausgelöst wird. Weitere Informationen über -Ereignisse finden Sie unter Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen.
Sie können Ihre DB-Ereignisse über die Amazon-RDS-Konsole oder mittels API-Operationen anzeigen.
Zeigen Sie den aktuellen Status Ihres Multi-AZ-DB-Clusters an, indem Sie die Amazon-RDS-Konsole, die AWS CLI und die RDS-API verwenden.
Informationen zur empfohlenen Vorgehensweise bei Failover-Situationen, zur Verringerung der Wiederherstellungsdauer und zu bewährten Methoden für Amazon RDS finden Sie unter Bewährte Methoden für Amazon RDS.
Festlegen des JVM-TTL-Werts für DNS-Name-Lookups
Bei dem Failover-Prozess wird der DNS-Datensatz (Domain Name System) der DB-Instance so geändert, dass er auf die Reader-DB-Instance verweist. Als Ergebnis müssen alle bestehenden Verbindungen zu Ihrer DB-Instance neu hergestellt werden. In einer JVM-Umgebung (Java Virtual Machine) müssen Sie aufgrund der besonderen Funktionsweise der Zwischenspeicherung von DNS-Informationen in Java möglicherweise die JVM-Einstellungen rekonfigurieren.
Die JVM speichert DNS-Name-Lookups zwischen. Wenn die JVM einen Hostnamen zu einer IP-Adresse auflöst, speichert sie die IP-Adresse für einen bestimmten Zeitraum zwischen. Diese Zeit ist als Time-to-Live (TTL, Lebensdauer) bekannt.
Da AWS-Ressourcen DNS-Namenseinträge nutzen, die sich gelegentlich ändern, empfehlen wir, dass Sie Ihre JVM mit einem TTL-Wert von maximal 60 Sekunden konfigurieren. Auf diese Weise wird bei Änderung der IP-Adresse einer Ressource sichergestellt, dass Ihre Anwendung die neue IP-Adresse der Ressource durch erneute Abfrage des DNS abrufen und nutzen kann.
Bei einigen Java-Konfigurationen ist die JVM-Standard-TTL so festgelegt, dass DNS-Einträge nie aktualisiert werden, bis die JVM neu gestartet wird. Ändert sich die IP-Adresse einer AWS-Ressource also, während Ihre Anwendung läuft, kann die Anwendung die Ressource erst wieder nutzen, nachdem Sie die JVM manuell neu starten und die zwischengespeicherten IP-Informationen aktualisiert wurden. In diesem Fall ist es wichtig, die TTL der JVM so einzustellen, dass sie die zwischengespeicherten IP-Daten von Zeit zu Zeit aktualisiert.
Anmerkung
Die Standard-TTL kann je nach Version Ihrer JVM und abhängig davon, ob ein Sicherheits-Manager installiert ist, unterschiedlich sein. Viele JVMs bieten eine Standard-TTL von weniger als 60 Sekunden. Wenn Sie eine solche JVM und keinen Sicherheits-Manager nutzen, können Sie den Rest dieses Themas ignorieren. Weitere Informationen zu Sicherheits-Managern in Oracle finden Sie unter The Security Manager
Um die TTL der JVM zu ändern, legen Sie den Eigenschaftswert networkaddress.cache.ttl
-
Legen Sie in der
networkaddress.cache.ttl-Datei$JAVA_HOME/jre/lib/security/java.securityfest, um den Eigenschaftswert global für alle Anwendungen festzulegen, die die JVM 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");
