Multi-AZ-DB-Cluster-Bereitstellungen

Eine Multi-AZ-DB-Cluster-Bereitstellung ist ein halbsynchroner, hochverfügbarer Bereitstellungsmodus von Amazon RDS mit zwei lesbaren Replikat-DB-Instances. Ein Multi-AZ-DB-Cluster verfügt über eine Schreiber-DB-Instance und zwei Leser-DB-Instances in drei separaten Availability Zones in der selben AWS-Region. Multi-AZ-DB-Cluster bieten hohe Verfügbarkeit, erhöhte Kapazität für Lese-Workloads und eine geringere Schreiblatenz im Vergleich zu Multi-AZ DB-Instance-Bereitstellungen.

Sie können Daten aus einer On-Premises-Datenbank in einen Multi-AZ-DB-Cluster importieren, indem Sie die Anweisungen unter Importieren von Daten in eine Amazon-RDS-MariaDB- oder MySQL-Datenbank mit reduzierter Ausfallzeit befolgen.

Sie können Reserved DB-Instances für einen Multi-AZ-DB-Cluster erwerben. Weitere Informationen finden Sie unter Reserved DB-Instances für einen Multi-AZ-DB-Cluster.

Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen zu Versions- und Regionsverfügbarkeit von Amazon RDS mit Multi-AZ-DB-Clustern finden Sie unter Multi-AZ-DB-Cluster.

Themen

• Verfügbarkeit der Instance-Klassen für Multi-AZ-DB-Cluster
• Übersicht über Multi-AZ-DB-Cluster
• Verwaltung eines Multi-AZ-DB-Clusters mit dem AWS Management Console
• Arbeiten mit Parametergruppen für Multi-AZ-DB-Cluster
• Aktualisierung der Engine-Version eines Multi-AZ-DB-Clusters
• Verwenden von RDS-Proxy mit Multi-AZ-DB-Clustern
• Replikatverzögerung und Multi-AZ-DB-Cluster
• Failover-Prozess für Multi-AZ-DB-Cluster
• Erstellen eines Multi-AZ-DB-Clusters
• Herstellen einer Verbindung zu einem Multi-AZ-DB-Cluster
• Automatisches Verbinden einer AWS-Rechenressource und eines Multi-AZ-DB-Clusters
• Ändern eines Multi-AZ-DB-Clusters
• Umbenennen eines Multi-AZ-DB-Clusters
• Neustart von Multi-AZ-DB-Clustern und Reader-DB-Instances
• Arbeiten mit Multi-AZ-DB-Cluster-Lesereplikaten
• Verwenden der logischen PostgreSQL-Replikation mit Multi-AZ-DB-Clustern
• Löschen eines Multi-AZ-DB-Clusters
• Einschränkungen von Multi-AZ-DB-Clustern

Wichtig

Multi-AZ-DB-Cluster sind nicht dasselbe wie Aurora-DB-Cluster. Informationen zu Aurora-DB-Clustern finden Sie im Amazon-Aurora-Benutzerhandbuch.

Verfügbarkeit der Instance-Klassen für Multi-AZ-DB-Cluster

Multi-AZ-DB-Cluster-Bereitstellungen werden für die folgenden DB-Instance-Klassen unterstützt:db.m5d,db.m6gd,m6id,db.m6idn,,db.r5d,db.r6gd, und db.x2iedndb.r6id, unddb.r6idn. db.c6gd

Anmerkung

Die c6gd-Instance-Klassen sind die einzigen, die die Instance-Größe unterstützen. medium

Weitere Informationen zu DB-Instance-Klassen finden Sie unter DB-Instance-Klassen.

Übersicht über Multi-AZ-DB-Cluster

Bei einem Multi-AZ-DB-Cluster repliziert Amazon RDS Daten von der Writer-DB-Instance auf beide Reader-DB-Instances mithilfe der nativen Replikationsfunktionen der DB-Engine. Wenn eine Änderung an der Writer-DB-Instance vorgenommen wird, wird sie an jede Reader-DB-Instance gesendet.

Multi-AZ-DB-Cluster-Bereitstellungen verwenden eine halbsynchrone Replikation, bei der eine Bestätigung von mindestens einer Reader-DB-Instance erforderlich ist, damit eine Änderung festgeschrieben wird. Es ist keine Bestätigung dafür erforderlich, dass die Ereignisse vollständig ausgeführt wurden und ein Commit für alle Replikate ausgeführt wurde.

Reader-DB-Instances fungieren als automatische Failover-Ziele und dienen auch dem Leseverkehr, um den Lesedurchsatz der Anwendung zu erhöhen. Wenn auf Ihrer Writer-DB-Instance ein Ausfall auftritt, verwaltet RDS das Failover auf eine der Reader-DB-Instances. RDS tut dies basierend darauf, welche Reader-DB-Instance über den neuesten Änderungsdatensatz verfügt.

Das folgende Diagramm zeigt einen Multi-AZ-DB-Cluster.

Multi-AZ-DB-Cluster haben in der Regel eine geringere Schreiblatenz im Vergleich zu Multi-AZ-DB-Instance-Bereitstellungen. Auch schreibgeschützte Workloads dürfen auf Reader-DB-Instances ausgeführt werden. Die RDS-Konsole zeigt die Availability Zone der Schreib-DB-Instance und die Availability Zones der Reader DB-Instances an. Sie können auch den describe-db-clustersCLI-Befehl oder den API-Vorgang DescribeDBClusters verwenden, um diese Informationen zu finden.

Wichtig

Um Replikatfehler in Multi-AZ-DB-Clustern von RDS für MySQL zu vermeiden, empfehlen wir dringend, dass alle Tabellen über einen Primärschlüssel verfügen sollten.

Verwaltung eines Multi-AZ-DB-Clusters mit dem AWS Management Console

Sie können einen Multi-AZ-DB-Cluster mit der Konsole verwalten.

So verwalten Sie einen Multi-AZ-DB-Cluster mit der Konsole

1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

2. Wählen Sie im Navigationsbereich Databases (Datenbanken) und dann den zu verwaltenden Multi-AZ-DB-Cluster aus.

Die folgende Abbildung zeigt einen Multi-AZ-DB-Cluster in der Konsole.

Die verfügbaren Aktionen im Menü Aktionen hängen davon ab, ob der Multi-AZ-DB-Cluster oder eine DB-Instance im Cluster ausgewählt ist.

Wählen Sie den Multi-AZ DB-Cluster aus, um die Cluster-Details anzuzeigen und Aktionen auf Clusterebene durchzuführen.

Wählen Sie eine DB-Instance in einem Multi-AZ-DB-Cluster aus, um die Details der DB-Instance anzuzeigen und Aktionen auf DB-Instance-Ebene durchzuführen.

Arbeiten mit Parametergruppen für Multi-AZ-DB-Cluster

In einem Multi-AZ-DB-Cluster fungiert eine DB-Cluster-Parametergruppe als Container für Engine-Konfigurationswerte, die auf jede DB-Instance im Multi-AZ-DB-Cluster angewendet werden.

In einem Multi-AZ-DB-Cluster wird eine DB-Parametergruppe auf die Standard-DB-Parametergruppe für die DB-Engine und die DB-Engine-Version festgelegt. Die Einstellungen in der Parametergruppe des DB-Clusters werden für alle DB-Instances im Cluster verwendet.

Informationen zu Parametergruppen finden Sie unter Arbeiten mit Parametergruppen.

Aktualisierung der Engine-Version eines Multi-AZ-DB-Clusters

Amazon RDS bietet neuere Versionen jeder unterstützten Datenbank-Engine, sodass Sie Ihren Multi-AZ-DB-Cluster auf dem neuesten Stand halten können. Wenn Amazon RDS eine neue Version einer Datenbank-Engine unterstützt, können Sie festlegen, wie und wann ein Upgrade für den Multi-AZ-DB-Cluster durchgeführt wird.

Es gibt zwei Arten von Upgrades, die Sie durchführen können:

Upgrades wichtiger Versionen

Ein Upgrade einer größeren Engine-Version kann Änderungen mit sich bringen, die nicht mit vorhandenen Anwendungen kompatibel sind. Wenn Sie ein Hauptversions-Upgrade initiieren, aktualisiert Amazon RDS gleichzeitig die Reader- und Writer-Instances. Daher ist Ihr DB-Cluster möglicherweise erst verfügbar, wenn das Upgrade abgeschlossen ist.

Upgrades kleinerer Versionen

Ein Nebenversion-Upgrade enthalten nur Änderungen, die abwärtskompatibel mit bestehenden Anwendungen sind. Wenn Sie ein Upgrade einer kleineren Version initiieren, aktualisiert Amazon RDS zunächst die Reader-DB-Instances nacheinander. Dann wird eine der Reader-DB-Instances zur neuen Writer-DB-Instance. Amazon RDS aktualisiert dann die alte Writer-Instance (die jetzt eine Reader-Instance ist).

Die Ausfallzeit während des Upgrades ist auf die Zeit beschränkt, die benötigt wird, bis eine der Reader-DB-Instances zur neuen Writer-DB-Instance wird. Diese Ausfallzeit wirkt wie ein automatischer Failover. Weitere Informationen finden Sie unter Failover-Prozess für Multi-AZ-DB-Cluster. Beachten Sie, dass sich die Replikatverzögerung Ihres Multi-AZ-DB-Clusters auf die Ausfallzeit auswirken kann. Weitere Informationen finden Sie unter Replikatverzögerung und Multi-AZ-DB-Cluster.

Für RDS for PostgreSQL Multi-AZ-DB-Cluster-Read Replicas aktualisiert Amazon RDS die Cluster-Mitgliedsinstanzen nacheinander. Die Clusterrollen „Reader“ und „Writer“ wechseln während des Upgrades nicht. Daher kann es in Ihrem DB-Cluster zu Ausfallzeiten kommen, während Amazon RDS die Cluster-Writer-Instance aktualisiert.

Anmerkung

Die Ausfallzeit für ein Upgrade der Nebenversion eines Multi-AZ-DB-Clusters beträgt in der Regel 35 Sekunden. Bei Verwendung mit RDS Proxy können Sie die Ausfallzeit weiter auf eine Sekunde oder weniger reduzieren. Weitere Informationen finden Sie unter Verwenden von Amazon RDS Proxy. Alternativ können Sie einen Open-Source-Datenbank-Proxy wie ProxySQL oder den AWS JDBC-Treiber PgBouncerfür MySQL verwenden.

Derzeit unterstützt Amazon RDS Hauptversions-Upgrades nur für RDS for PostgreSQL Multi-AZ DB-Cluster. Amazon RDS unterstützt kleinere Versions-Upgrades für alle DB-Engines, die Multi-AZ-DB-Cluster unterstützen.

Amazon RDS aktualisiert Lesereplikate von Multi-AZ-DB-Clustern nicht automatisch. Bei Upgrades kleinerer Versionen müssen Sie zuerst alle Read Replicas manuell aktualisieren und dann den Cluster aktualisieren. Andernfalls wird das Upgrade blockiert. Bei Upgrades der Hauptversion eines Clusters ändert sich der Replikationsstatus aller Lesereplikate in Beendet. Sie müssen die Lesereplikate nach Abschluss des Upgrades löschen und neu erstellen. Weitere Informationen finden Sie unter Überwachen der Lesereplikation.

Der Vorgang für das Upgrade der Engine-Version eines Multi-AZ-DB-Clusters entspricht dem Vorgang für das Upgrade der Version einer DB-Instance-Engine. Anweisungen finden Sie unter Upgrade der Engine-Version für eine DB-Instance. Der einzige Unterschied besteht darin, dass Sie bei der Verwendung von AWS Command Line Interface (AWS CLI) den modify-db-clusterBefehl verwenden und den --db-cluster-identifier Parameter (zusammen mit dem --allow-major-version-upgrade Parameter) angeben.

Weitere Informationen zu Haupt- und Nebenversions-Upgrades finden Sie in der folgenden Dokumentation für Ihre DB-Engine:

• Aktualisieren einer PostgreSQL-DB-Engine für Amazon RDS

• Aktualisieren der MySQL DB-Engine

Verwenden von RDS-Proxy mit Multi-AZ-DB-Clustern

Sie können Amazon RDS Proxy verwenden, um einen Proxy für Ihre Multi-AZ-DB-Cluster zu erstellen. Durch die Verwendung von RDS Proxy können Ihre Anwendungen Datenbankverbindungen bündeln und gemeinsam nutzen, um ihre Skalierbarkeit zu verbessern. Jeder Proxy führt Verbindungsmultiplexing durch, was auch als Wiederverwendung von Verbindungen bezeichnet wird. Beim Multiplexing führt RDS-Proxy alle Operationen für eine Transaktion mit einer zugrunde liegenden Datenbankverbindung aus. RDS Proxy kann auch die Ausfallzeit für ein kleineres Versionsupgrade eines Multi-AZ-DB-Clusters auf eine Sekunde oder weniger reduzieren. Weitere Informationen zu den Vorteilen von RDS-Proxy finden Sie unter Verwenden von Amazon RDS Proxy.

Wenn Sie einen Proxy für einen Multi-AZ-DB-Cluster einrichten möchten, wählen Sie während der Cluster-Erstellung RDS-Proxy erstellen aus. Anweisungen zum Erstellen und Verwalten von RDS-Proxy-Endpunkten finden Sie unter Arbeiten mit Amazon RDS Proxy-Endpunkten.

Replikatverzögerung und Multi-AZ-DB-Cluster

Die Replikatverzögerung ist der Zeitunterschied zwischen der neuesten Transaktion auf der Writer-DB-Instance und der zuletzt angewendeten Transaktion auf einer Reader-DB-Instance. Die CloudWatch Amazon-Metrik ReplicaLag repräsentiert diesen Zeitunterschied. Weitere Informationen zu CloudWatch Metriken finden Sie unterÜberwachen von Amazon RDS-Metriken mit Amazon CloudWatch.

Obwohl Multi-AZ-DB-Cluster eine hohe Schreibleistung ermöglichen, kann eine Replikatverzögerung aufgrund der Art der Engine-basierten Replikation immer noch auftreten. Da jedes Failover zuerst die Replikatverzögerung auflösen muss, bevor es eine neue Writer-DB-Instance fördert, ist die Überwachung und Verwaltung dieser Replikatverzögerung eine Überlegung wert.

Bei Multi-AZ-DB-Clustern von RDS for MySQL hängt die Failover-Zeit von der Replikatverzögerung der beiden verbleibenden Reader-DB-Instances ab. Beide Reader-DB-Instances müssen nicht angewendete Transaktionen anwenden, bevor eine von ihnen auf die neue Writer-DB-Instance befördert wird.

Bei Multi-AZ-DB-Clustern von RDS for PostgreSQL hängt die Failover-Zeit von der kleinsten Replikatverzögerung der beiden verbleibenden Reader-DB-Instances ab. Die Reader-DB-Instance mit der kleinsten Replikatverzögerung muss nicht angewendete Transaktionen anwenden, bevor sie auf die neue Writer-DB-Instance befördert wird.

Ein Tutorial, das Ihnen zeigt, wie Sie einen CloudWatch Alarm erstellen, wenn die Replikatverzögerung einen bestimmten Zeitraum überschreitet, finden Sie unterTutorial: Erstellen eines Amazon-CloudWatch-Alarms für Multi-AZ-DB-Cluster-Replikatverzögerung.

Häufige Ursachen für Replikatverzögerung

Im Allgemeinen tritt eine Replikatverzögerung auf, wenn die Write-Workload zu hoch ist, als dass die Reader-DB-Instances die Transaktionen effizient anwenden könnten. Verschiedene Workloads können eine vorübergehende oder kontinuierliche Replikatverzögerung verursachen. Einige gängige Beispiele:

• Hohe Write-Parallelität oder starke Batch-Aktualisierung auf der Writer-DB-Instance, wodurch der Anwendungsprozess auf den Reader-DB-Instances zurückbleibt.

• Starke Read-Workload, die Ressourcen auf einer oder mehreren Reader-DB-Instances verwendet. Das Ausführen langsamer oder großer Abfragen kann sich auf den Anwendungsprozess auswirken und die Replikatverzögerung verursachen.

• Transaktionen, die große Datenmengen oder DDL-Anweisungen ändern, können manchmal zu einer vorübergehenden Zunahme der Replikatverzögerung führen, da die Datenbank die Commit-Reihenfolge beibehalten muss.

Minderung der Replikatverzögerung

Bei Multi-AZ-DB-Clustern für RDS for MySQL und RDS for PostgreSQL können Sie Replikatverzögerung verringern, indem Sie die Belastung Ihrer Writer-DB-Instance reduzieren. Sie können auch die Flusssteuerung verwenden, um Replikatverzögerung zu reduzieren. Die Flusssteuerung funktioniert, indem Schreibvorgänge auf der Writer-DB-Instance gedrosselt werden, wodurch sichergestellt wird, dass die Replikatverzögerung nicht unbegrenzt weiter zunimmt. Die Schreibdrosselung wird erreicht, indem am Ende einer Transaktion eine Verzögerung hinzugefügt wird, wodurch der Schreibdurchsatz auf der Writer-DB-Instance verringert wird. Obwohl die Flusskontrolle nicht garantiert, Verzögerungen zu verhindern, kann sie dazu beitragen, die allgemeine Verzögerung bei vielen Workloads zu reduzieren. Die folgenden Abschnitte enthalten Informationen zur Verwendung der Flusssteuerung mit RDS for MySQL und RDS for PostgreSQL.

Minderung der Replikatverzögerung durch Flusssteuerung für RDS for MySQL

Wenn Sie die Multi-AZ-DB-Cluster von RDS for MySQL verwenden, ist die Flusssteuerung standardmäßig mit dem dynamischen Parameter rpl_semi_sync_master_target_apply_lag aktiviert. Dieser Parameter gibt die Obergrenze an, die für die Replikatverzögerung gewünscht wird. Wenn sich die Replikatverzögerung diesem konfigurierten Grenzwert nähert, drosselt die Flusssteuerung die Schreibtransaktionen auf der Writer-DB-Instance, um zu versuchen, die Replikatverzögerung unter den angegebenen Wert zu halten. In einigen Fällen kann die Replikatverzögerung den angegebenen Grenzwert überschreiten. Standardmäßig ist dieser Parameter auf 120 Sekunden eingestellt. Um die Flusskontrolle auszuschalten, setzen Sie diesen Parameter auf seinen Maximalwert von 86.400 Sekunden (ein Tag).

Um die aktuelle Verzögerung anzuzeigen, die von der Flusssteuerung injiziert wird, zeigen Sie den Parameter Rpl_semi_sync_master_flow_control_current_delay an, indem Sie die folgende Abfrage ausführen.

SHOW GLOBAL STATUS like '%flow_control%';

Ihre Ausgabe sollte in etwa wie folgt aussehen.

+-------------------------------------------------+-------+
| Variable_name                                   | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010  |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)

Anmerkung

Die Verzögerung wird in Mikrosekunden angezeigt.

Wenn Sie Performance Insights für einen Multi-AZ-DB-Cluster von RDS for MySQL aktiviert haben, können Sie das Wait-Ereignis überwachen, das einer SQL-Anweisung entspricht, die angibt, dass die Abfragen durch ein Flusssteuerelement verzögert wurden. Wenn eine Verzögerung durch ein Flusssteuerungselement eingeführt wurde, können Sie das Wait-Rreignis /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond anzeigen, das der SQL-Anweisung im Performance-Insights-Dashboard entspricht. Stellen Sie sicher, dass das Leistungsschema aktiviert ist, um diese Metriken anzuzeigen. Weitere Informationen zu Performance Insights finden Sie unter Überwachung mit Performance Insights auf Amazon RDS.

Minderung der Replikatverzögerung durch Flusssteuerung für RDS for PostgreSQL

Wenn Sie die Multi-AZ-DB-Cluster von RDS for PostgreSQL verwenden, wird die Flusssteuerung als Erweiterung bereitgestellt. Sie aktiviert einen Hintergrund-Worker für alle DB-Instances im DB-Cluster. Standardmäßig kommunizieren die Hintergrund-Worker auf den Reader-DB-Instances die aktuelle Replikatverzögerung mit dem Hintergrund-Worker auf der Writer-DB-Instance. Wenn die Verzögerung bei einer Reader-DB-Instance zwei Minuten überschreitet, fügt der Hintergrund-Worker der Writer-DB-Instance am Ende einer Transaktion eine Verzögerung hinzu. Um den Verzögerungsschwellenwert zu steuern, verwenden Sie den Parameter flow_control.target_standby_apply_lag.

Wenn eine Flusskontrolle einen PostgreSQL-Prozess drosselt, weist das Warteereignis Extension in pg_stat_activity und Performance Insights darauf hin. Die Funktion get_flow_control_stats zeigt Details darüber an, wie viel Verzögerung gerade hinzugefügt wird.

Die Flusskontrolle kann den meisten Workloads bei der Online-Transaktionsverarbeitung (OLTP) zugute kommen, die kurze, aber sehr gleichzeitige Transaktionen aufweisen. Wenn die Verzögerung durch lang andauernde Transaktionen wie Batchvorgänge verursacht wird, bietet die Flusskontrolle keinen so starken Vorteil.

Sie können die Flusskontrolle ausschalten, indem Sie die Erweiterung aus preload_shared_libraries entfernen und Ihre DB-Instance neu starten.

Failover-Prozess für Multi-AZ-DB-Cluster

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. 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.

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 ein manuelles Failover für einen Multi-AZ-DB-Cluster durchführen, beendet RDS zunächst die primäre DB-Instance. 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 mithilfe der AWS Management Console, der oder der AWS CLI RDS-API durchführen.

Konsole

Manuelles Ausfallen eines Multi-AZ-DB-Clusters

1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

2. Wählen Sie im Navigationsbereich Datenbanken aus.

3. Wählen Sie den Multi-AZ-DB-Cluster aus, den Sie ausfallen möchten.

4. Wählen Sie für Aktionen die Option Failover aus.

   Die Seite für den Failover-DB-Cluster wird angezeigt.

5. Wählen Sie Failover, um das manuelle Failover zu bestätigen.

AWS CLI

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-identifier mymultiazdbcluster

RDS-API

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 mithilfe der Amazon RDS-Konsole AWS CLI, der und der RDS-API 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 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 in eine IP-Adresse auflöst, speichert sie die IP-Adresse für einen bestimmten Zeitraum, der time-to-liveals (TTL) bezeichnet wird.

Da AWS Ressourcen DNS-Namenseinträge verwenden, die sich gelegentlich ändern, empfehlen wir, dass Sie Ihre JVM mit einem TTL-Wert von nicht mehr als 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. Wenn sich also die IP-Adresse einer AWS Ressource ändert, während Ihre Anwendung noch läuft, kann sie diese Ressource erst verwenden, wenn Sie die JVM manuell neu starten und die zwischengespeicherten IP-Informationen aktualisiert werden. 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 in der Oracle-Dokumentation.

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.security fest, 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.ttl im Initialisierungscode Ihrer Anwendung fest, bevor Netzwerkverbindungen hergestellt werden.

  
  java.security.Security.setProperty("networkaddress.cache.ttl" , "60");