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 auf einen Infrastrukturdefekt zurückzuführen ist, 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 Failover abgeschlossen ist, kann es länger dauern, bis die RDS Konsole die neue Availability Zone wiedergibt.
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 wickelt Failovers automatisch ab, sodass Sie den Datenbankbetrieb so schnell wie möglich ohne administrativen Eingriff wieder aufnehmen können. 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 in einem Offline-Vorgang 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 eines Verlusts der Netzwerkkonnektivität nicht erreichbar. |
RDSBei der Überwachung wurde ein Fehler bei der Netzwerkerreichbarkeit der primären DB-Instance festgestellt und ein Failover ausgelöst. |
Die RDS Instanz wurde vom Kunden geändert. |
Eine Änderung der RDS DB-Instance löste einen Failover aus. Weitere Informationen finden Sie unter Ändern einer Amazon RDS DB-Instance. |
Die primäre RDS Multi-AZ-Instance ist ausgelastet 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. |
Auf dem Speichervolume, das dem primären Host der RDS Multi-AZ-Instance zugrunde liegt, ist ein Fehler aufgetreten. |
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:
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 Konsole oder mithilfe von API Operations an.
Zeigen Sie den aktuellen Status Ihrer Multi-AZ-DB-Instance-Bereitstellung mithilfe der RDS Konsole oder mithilfe von API Operations 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 Standby-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.
Sie können die JVM Standardeinstellung abrufen, TTL indem Sie den Eigenschaftswert abrufen: networkaddress.cache.ttl
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
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 Eigenschaftswert fest. Nutzen Sie dazu eine der folgenden Methoden je nach Ihrem Bedarf:
-
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");
