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 einer Multi-AZ-DB-Instance für Amazon RDS
Wenn ein geplanter oder ungeplanter Ausfall Ihrer Multi-AZ-DB-Instance durch einen Infrastrukturdefekt resultiert, wechselt Amazon RDS automatisch zu einem Standby-Replikat in einer anderen Availability Zone.
Die Dauer, bis der Failover-Prozess für die Instance abgeschlossen ist, hängt von der Datenbankaktivität sowie von anderen Bedingungen zu dem Zeitpunkt ab, an dem die primäre DB-Instance ausgefallen ist. Der Failover-Prozess dauert normalerweise 60–120 Sekunden. Diese Failover-Dauer kann sich verlängern, wenn umfangreiche Transaktionen oder zeitintensive Wiederherstellungsprozesse durchgeführt werden. 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.
Anmerkung
Sie können ein Failover manuell erzwingen, wenn Sie eine Multi-AZ-DB-Instance neu starten. Weitere Informationen finden Sie unter Neustarten einer DB-Instance.
Amazon RDS führt den Failover-Prozess automatisch durch, sodass der Datenbankbetrieb so schnell wie möglich und ohne Verwaltungseingriff wieder aufgenommen werden kann. Die primäre DB-Instance schaltet automatisch auf das Standby-Replikat um, wenn eine der in der folgenden Tabelle beschriebenen Bedingungen eintritt: Sie können diese Failover-Gründe im Ereignisprotokoll einsehen.
| Failover-Grund | Beschreibung |
|---|---|
Das Betriebssystem, das der RDS-Datenbank-Instance zugrunde liegt, wird offline gepatcht. |
Ein Failover wurde während des Wartungsfensters für einen Betriebssystem-Patch oder ein Sicherheitsupdate ausgelöst. Weitere Informationen finden Sie unter Warten einer DB-Instance. |
Der primäre Host der RDS-Multi-AZ-Instance ist fehlerhaft. |
Die Multi-AZ-DB-Instance-Bereitstellung hat eine beeinträchtigte primäre DB-Instance erkannt und ein Failover eingeleitet. |
Der primäre Host der RDS-Multi-AZ-Instance ist aufgrund des Verlusts der Netzwerkverbindung nicht erreichbar. |
Die RDS-Überwachung hat einen Fehler bei der Erreichbarkeit des Netzwerks für die primäre DB-Instance festgestellt und ein Failover ausgelöst. |
Die RDS-Instance wurde vom Kunden geändert. |
Eine Änderung der RDS-DB-Instance hat ein Failover ausgelöst. Weitere Informationen finden Sie unter Ändern einer Amazon-RDS-DB-Instance. |
Die primäre RDS-Multi-AZ-Instance ist beschäftigt und reagiert nicht. |
Die primäre DB-Instance reagiert nicht. Wir empfehlen Folgendes:
Weitere Informationen zu diesen Empfehlungen finden Sie unter Überwachungstools für Amazon RDS und Bewährte Methoden für Amazon RDS. |
Das Speichervolumen, das dem primären Host der RDS-Multi-AZ-Instance zugrunde liegt, ist ausgefallen. |
Die Multi-AZ-DB-Instance-Bereitstellung hat ein Speicherproblem der primären DB-Instance erkannt und ein Failover eingeleitet. |
Der Benutzer hat ein Failover der DB-Instance angefordert. |
Sie haben die DB-Instance neu gestartet und Neustart mit Failover gewählt. Weitere Informationen finden Sie unter Neustarten einer DB-Instance. |
Um festzustellen, ob Ihre Multi-AZ-DB-Instance 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 RDS-Konsole oder mittels API-Operationen anzeigen.
Zeigen Sie den aktuellen Status Ihrer Multi-AZ-DB-Instance-Bereitstellung mithilfe der RDS-Konsole oder API-Vorgänge an.
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 Standby-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.
Sie erhalten die JVM-Standard-TTL, indem Sie den Eigenschaftswert networkaddress.cache.ttl
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
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 fest. Nutzen Sie dazu eine der folgenden Methoden je nach Ihrem Bedarf:
-
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");
