Multi-AZ-DB-Cluster-Bereitstellungen - Amazon Relational Database Service

Multi-AZ-DB-Cluster-Bereitstellungen

Eine Multi-AZ-DB-Cluster-Bereitstellung ist ein Bereitstellungsmodus für Hochverfügbarkeit von Amazon RDS mit zwei lesbaren Standby-DB-Instances. Ein Multi-AZ-DB-Cluster verfügt über eine Writer-DB-Instance und zwei Reader-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.

Wichtig

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

Ü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. Eine Bestätigung von mindestens einer Reader-DB-Instance ist erforderlich, damit eine Änderung festgeschrieben wird.

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

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 diese Informationen auch mit dem CLI-Befehl describe-db-clusters oder der API-Operation DescribeDBClusters finden.

Derzeit sind Multi-AZ-DB-Cluster nur in einigen AWS-Regionen verfügbar. Weitere Informationen zu AWS-Region, die Multi-AZ-DB-Cluster unterstützen, finden Sie unter Einschränkungen für Multi-AZ-DB-Cluster.

Erstellen und Verwalten eines Multi-AZ-DB-Clusters

Sie können einen Multi-AZ-DB-Cluster direkt erstellen oder indem Sie ihn aus einem Snapshot wiederherstellen. Anweisungen hierzu finden Sie in den folgenden Themen:

Sie können eine Multi-AZ-DB ändern, neu starten oder löschen, indem Sie den Anweisungen in diesen Themen folgen:

Sie können einen Snapshot eines Multi-AZ-DB-Clusters erstellen, indem Sie die Anweisungen unter Erstellen eines Multi-AZ-DB-Cluster-Snapshots befolgen.

Sie können einen Multi-AZ-DB-Cluster zu einem bestimmten Zeitpunkt wiederherstellen, indem Sie die Anweisungen in Wiederherstellen eines Multi-AZ-DB-Clusters zu einer bestimmten Zeit befolgen.

Verwalten von Verbindungen für Multi-AZ-DB-Cluster

Ein Multi-AZ-DB-Cluster verfügt über drei DB-Instances anstelle einer einzigen DB-Instance. Jede Verbindung wird von einer bestimmten DB-Instance verarbeitet. Wenn Sie eine Verbindung zu einem Multi-AZ-DB-Cluster herstellen, verweisen der von Ihnen angegebene Hostname und Port auf einen vollqualifizierten Domänennamen, der als Endpunkt bezeichnet wird. Der Multi-AZ-DB-Cluster verwendet den Endpunktmechanismus, um diese Verbindungen zu abstrahieren. Sie müssen daher für das Umleiten von Verbindungen nicht alle Hostnamen fest codieren oder Ihre eigene Logik schreiben, wenn einige DB-Instances nicht verfügbar sind.

Der Writer-Endpunkt stellt eine Verbindung zur Writer-DB-Instance des DB-Clusters her, der sowohl Lese- als auch Schreibvorgänge unterstützt. Der Leser-Endpunkt stellt eine Verbindung zu einer der beiden Reader-DB-Instances her, die nur Leseoperationen unterstützen.

Ihrem Anwendungsfall entsprechend können Sie mit Endpunkten jede Verbindung der entsprechenden DB-Instance oder Gruppe von DB-Instances zuordnen. Um beispielsweise DDL- und DML-Anweisungen auszuführen, können Sie eine Verbindung zu einer beliebigen DB-Instance herstellen, die die Writer-DB-Instance ist. Um Abfragen durchzuführen, können Sie eine Verbindung zum Leser-Endpunkt herstellen, wobei der Multi-AZ-DB-Cluster automatisch Verbindungen zwischen den Reader-DB-Instances verwaltet. Zur Diagnose und Optimierung können Sie eine Verbindung mit einem spezifischen DB-Instance-Endpunkt herstellen, um die Details einer bestimmten DB-Instance zu untersuchen.

Weitere Information über das Verbinden mit der DB-Instance finden Sie unter Herstellen einer Verbindung mit einer Amazon RDS-DB-Instance.

Arten von Multi-AZ-DB-Cluster-Endpunkten

Ein Endpunkt wird durch einen eindeutigen Bezeichner dargestellt, der eine Hostadresse enthält. In einem Multi-AZ-DB-Cluster stehen die folgenden Endpunkt-Typen zur Verfügung:

Cluster-Endpunkt

Ein Cluster-Endpunkt (oder Writer-Endpunkt) für einen Multi-AZ-DB-Cluster stellt eine Verbindung mit der aktuellen Writer-DB-Instance für diesen DB-Cluster her. Nur dieser Endpunkt kann Schreibvorgänge wie z. B. DDL- und DML-Anweisungen durchführen. Dieser Endpunkt kann auch Leseoperationen ausführen.

Jeder Multi-AZ-DB-Cluster verfügt über einen Cluster-Endpunkt und eine Writer-DB-Instance.

Sie verwenden den Cluster-Endpunkt für alle Schreibvorgänge auf dem DB-Cluster, darunter Einfügungs-, Aktualisierungs- und Löschvorgänge sowie DDL-Änderungen. Sie können den Cluster-Endpunkt auch für Lesevorgänge nutzen, beispielsweise Abfragen.

Wenn die aktuelle Writer-DB-Instance eines DB-Clusters ausfällt, wechselt der Multi-AZ-DB-Cluster automatisch zu einer neuen Writer-DB-Instance. Während eines Failovers bedient der DB-Cluster weiterhin Verbindungsanfragen von der neuen Schreib-DB-Instance an den Cluster-Endpunkt mit minimaler Serviceunterbrechung.

Das folgende Beispiel zeigt einen Cluster-Endpunkt für einen Multi-AZ-DB-Cluster.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com

Leser-Endpunkt

Ein Reader-Endpunkt für einen Multi-AZ-DB-Cluster bietet Unterstützung für schreibgeschützte Verbindungen zum DB-Cluster. Verwenden Sie den Leser-Endpunkt für Lesevorgänge, beispielsweise Abfragen. Durch die Verarbeitung dieser Anweisungen auf den Reader-DB-Instances reduziert dieser Endpunkt den Overhead auf der Writer-DB-Instance. Es hilft dem Cluster auch, die Kapazität zu skalieren, um gleichzeitige SELECT-Abfragen zu verarbeiten. Jeder Multi-AZ-DB-Cluster verfügt über einen Reader-Endpunkt.

Der Leser-Endpunkt sendet jede Verbindungsanforderung an eine der Reader-DB-Instances. Wenn Sie den Reader-Endpunkt für eine Sitzung verwenden, können Sie in dieser Sitzung nur schreibgeschützte Anweisungen wie SELECT ausführen.

Das folgende Beispiel zeigt einen Leser-Endpunkt für einen Multi-AZ-DB-Cluster.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com

Instance-Endpunkt

Ein Instance-Endpunkt stellt innerhalb eines DB-Instance eine Verbindung zu einer spezifischen Multi-AZ-DB-Cluster her. Jede DB-Instance in einem DB-Cluster hat einen eigenen, spezifischen Instance-Endpunkt. Es gibt also einen Instance-Endpunkt für die aktuelle Writer-DB-Instance des DB-Clusters und einen Instance-Endpunkt für jede der Reader-DB-Instances im DB-Cluster.

Der Instance-Endpunkt bietet direkte Kontrolle über Verbindungen zum DB-Cluster. Dieses Steuerelement kann Ihnen helfen, Szenarien zu beheben, in denen die Verwendung des Cluster-Endpunkts oder des Leser-Endpunkts möglicherweise nicht angemessen ist. Beispiel: Ihre Client-Anwendung erfordert möglicherweise einen detaillierteren Lastausgleich je nach Workload-Typ. In diesem Fall können Sie mehrere Clients so konfigurieren, dass sie sich mit verschiedenen Reader-DB-Instances in einem DB-Cluster verbinden, um Leseworkloads zu verteilen.

Das folgende Beispiel zeigt einen Instance-Endpunkt für eine DB-Instance in einem Multi-AZ-DB-Cluster.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com

Anzeigen der Endpunkte für einen Multi-AZ-DB-Cluster

In der AWS Management Console sehen Sie den Cluster-Endpunkt und den Reader-Endpunkt auf der Detailseite für jeden Multi-AZ-DB-Cluster. Der Instance-Endpunkt wird auf der Detailseite der jeweiligen DB-Instance angezeigt.

Mit der AWS CLI sehen Sie die Writer- und Reader-Endpunkte in der Ausgabe des Befehls describe-db-clusters . Der folgende Befehl zeigt beispielsweise die Endpunktattribute für alle Cluster in Ihrer aktuellen AWS-Region an.

aws rds describe-db-cluster-endpoints

Mit der Amazon RDS-API rufen Sie die Endpunkte ab, indem Sie die Funktion DescribeDBClusterEndpoints aufrufen. Die Ausgabe zeigt auch Amazon-Aurora-DB-Cluster-Endpunkte an, falls vorhanden.

Verwenden des Cluster-Endpunkts

Jeder Multi-AZ-DB-Cluster verfügt über einen einzelnen integrierten Cluster-Endpunkt, dessen Name und andere Attribute von Amazon RDS verwaltet werden. Sie können einen solchen Endpunkt nicht erstellen, löschen oder ändern.

Den Cluster-Endpunkt verwenden Sie beim Verwalten Ihres DB-Clusters, bei Extraktions-, Transformations- und Ladevorgängen (ETL) oder beim Entwickeln und Testen von Anwendungen. Der Cluster-Endpunkt stellt eine Verbindung zur Writer-DB-Instance des Clusters her. Die Writer-DB-Instance ist die einzige DB-Instance, mit der Sie Tabellen und Indizes erstellen sowie INSERT-Anweisungen und andere DDL- und DML-Operationen ausführen können.

Die physische IP-Adresse, auf die der Cluster-Endpunkt verweist, ändert sich, wenn der Failover-Mechanismus eine neue DB-Instance zur Writer-DB-Instance für den Cluster heraufsetzt. Wenn Sie irgendeine Form von Verbindungspooling oder eine andere Art von Multiplexing verwenden, müssen Sie möglicherweise zwischengespeicherte DNS-Informationen löschen oder die entsprechende Time-to-Live reduzieren. Hierdurch wird sichergestellt, dass Sie keine Lese-Schreib-Verbindung mit einer DB-Instance herstellen, die nicht mehr verfügbar ist oder nach einem Failover schreibgeschützt ist.

Verwenden des Leser-Endpunkts

Sie verwenden den Reader-Endpunkt für schreibgeschützte Verbindungen zu Ihrem Multi-AZ-DB-Cluster. Dieser Endpunkt hilft Ihrem DB-Cluster bei der Handhabung einer abfragenintensiven Workload. Der Reader-Endpunkt ist der Endpunkt, den Sie Anwendungen zur Verfügung stellen, die Berichterstattung oder andere schreibgeschützte Operationen auf dem Cluster ausführen. Der Leser-Endpunkt sendet Verbindungen zu verfügbaren Reader-DB-Instances in einem Multi-AZ-DB-Cluster.

Jeder Multi-AZ-Cluster verfügt über einen integrierten Cluster-Endpunkt verfügt, dessen Name zusammen mit anderen Attributen durch Amazon RDS verwaltet wird. Sie können einen solchen Endpunkt nicht erstellen, löschen oder ändern.

Verwenden der Instance-Endpunkte

Jede DB-Instance in einem Multi-AZ-DB-Cluster verfügt über ihren eigenen integrierten Instance-Endpunkt, dessen Name und andere Attribute von Amazon RDS verwaltet werden. Sie können einen solchen Endpunkt nicht erstellen, löschen oder ändern. Bei einem Multi-AZ-DB-Cluster verwenden Sie in der Regel die Writer- und Reader-Endpunkte häufiger als die Instance-Endpunkte.

Bei täglichen Operationen werden Instance-Endpunkte hauptsächlich dazu verwendet, um Kapazitäts- oder Leistungsprobleme zu untersuchen, die eine spezifische Instance in einem Multi-AZ-DB-Cluster betreffen. Während eine Verbindung zu einer spezifischen DB-Instance besteht, können Sie unter anderem deren Statusvariablen oder Metriken untersuchen. Hierdurch ist es möglich, Unterschiede zwischen den Aktivitäten verschiedener Cluster-DB-Instances zu ermitteln.

Funktionsweise von Multi-AZ-DB-Endpunkten mit hoher Verfügbarkeit

Verwenden Sie im Fall von Multi-AZ-DB-Clustern, bei denen eine hohe Verfügbarkeit von großer Bedeutung ist, den Writer-Endpunkt für Lese-/Schreib- oder Allzweck-Verbindungen und den Leser-Endpunkt für schreibgeschützte Verbindungen. Die Schreiber- und Leser-Endpunkte verwalten das Failover von DB-Instances besser als Instance-Endpunkte. Im Gegensatz zu den Instance-Endpunkten ändern die Schreiber- und Leser-Endpunkte automatisch, mit welcher DB-Instance sie eine Verbindung herstellen, wenn eine DB-Instance in Ihrem Cluster nicht mehr verfügbar ist.

Wenn die Writer-DB-Instance eines DB-Clusters ausfällt, führt Amazon RDS automatisch ein Failover zu einer neuen Writer-DB-Instance durch. Dies geschieht durch die Förderung einer Reader-DB-Instance auf eine neue Writer-DB-Instance. Wenn ein Failover auftritt, können Sie den Schreiber-Endpunkt verwenden, um eine Verbindung zu der neu hochgestuften Writer-DB-Instance wiederherzustellen. Oder Sie können den Leser-Endpunkt verwenden, um eine Verbindung zu einer der Reader-DB-Instances im DB-Cluster wiederherzustellen. Während eines Failovers leitet der Reader-Endpunkt Verbindungen möglicherweise für kurze Zeit an die neue Writer-DB-Instance eines DB-Clusters weiter, nachdem eine Reader-DB-Instance zur neuen Writer-DB-Instance hochgestuft wurde. Wenn Sie Ihre Anwendungslogik so entwickeln, dass Verbindungen zu Instance-Endpunkten verwaltet werden können, ist es möglich, den daraus resultierenden Satz an verfügbaren DB-Instances im DB-Cluster manuell oder programmgesteuert zu ermitteln.

Verwalten eines Multi-AZ-DB-Clusters mit 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 AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole 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.


				Multi-AZ-DB-Cluster in der AWS Management Console

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.


				Multi-AZ-DB-Cluster-Aktionen in der AWS Management Console

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.


				DB-Instance-Aktionen in einem Multi-AZ-DB-Cluster in der AWS Management Console

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.

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 Amazon-CloudWatch-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 Lernprogramm, das Ihnen zeigt, wie Sie einen CloudWatch-Alarm erstellen, wenn die Replikatverzögerung einen bestimmten Zeitraum überschreitet, finden Sie unter Tutorial: 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 Limit nähert, drosselt die Flusssteuerung die Schreibtransaktionen auf der Writer-DB-Instance, um zu versuchen, die Replikatverzögerung unter dem angegebenen Wert einzudämmen. In einigen Fällen kann die Replikatverzögerung den angegebenen Grenzwert überschreiten. Standardmäßig ist dieser Parameter auf 120 Sekunden eingestellt. Um die Flusssteuerung auszuschalten, stellen Sie diesen Parameter auf seinen Maximalwert von 86400 Sekunden (ein Tag) ein.

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%';

Die Ausgabe sieht folgendermaßen oder ähnlich aus.

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

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

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

  2. Wählen Sie im Navigationsbereich Databases (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 Failover-DB-Cluster wird angezeigt.

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

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 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");

Einschränkungen für Multi-AZ-DB-Cluster

Die folgenden Einschränkungen gelten für Multi-AZ-DB-Cluster:

  • Sie können einen Multi-AZ-DB-Cluster nur mit MySQL Version 8.0.28 und höheren 8.0-Versionen sowie PostgreSQL Version 13.4 erstellen.

  • Sie können Multi-AZ-DB-Cluster nur in den folgenden AWS-Regionen erstellen:

    • USA Ost (Ohio)

    • USA Ost (Nord-Virginia)

    • USA West (Oregon)

    • Asien-Pazifik (Singapur)

    • Asien-Pazifik (Sydney)

    • Asien-Pazifik (Tokio)

    • Europa (Irland)

  • Multi-AZ-DB-Cluster unterstützen nur bereitgestellten IOPS-Speicher.

  • Sie können eine Single-AZ-DB-Instance-Bereitstellung oder Multi-AZ-DB-Instance-Bereitstellung nicht in einen Multi-AZ-DB-Cluster ändern. Alternativ können Sie einen Snapshot einer Bereitstellung einer Single-AZ-DB-Instance oder einer Bereitstellung einer Multi-AZ-DB-Instance in einem Multi-AZ-DB-Cluster wiederherstellen.

  • Sie können keinen Multi-AZ-DB-Cluster-Snapshot in einer Multi-AZ-DB-Instance-Bereitstellung oder bei Single-AZ-Bereitstellungen wiederherstellen.

  • Multi-AZ DB-Cluster unterstützen keine Änderungen auf DB-Instance-Ebene, da alle Änderungen auf DB-Cluster-Ebene vorgenommen werden.

  • Multi-AZ-DB-Cluster unterstützen die folgenden Funktionen nicht:

    • Amazon RDS Proxy

    • AWS Backup

    • AWS CloudFormation

    • Exportieren von Multi-AZ-DB-Cluster-Snapshot-Daten in einen Amazon-S3-Bucket

    • IAM DB authentication (IAM-DB-Authentifizierung)

    • Kerberos-Authentifizierung

    • Integration in AWS Secrets Manager

    • Ändern des Ports

      Alternativ können Sie einen Multi-AZ-DB-Cluster zu einem bestimmten Zeitpunkt wiederherstellen und einen anderen Port angeben.

    • Optionsgruppen

    • Read Replicas

    • Reservierte DB-Instances

    • Wiederherstellen eines Multi-AZ-DB-Cluster-Snapshots aus einem Amazon-S3-Bucket

    • Auto Scaling des Speichers durch Festlegen des maximal zugewiesenen Speichers

      Alternativ können Sie den Speicher manuell skalieren.

    • Stoppen und Starten des DB-Clusters.

    • Kontoübergreifende DB-Instance- und DB-Cluster-Snapshots

  • RDS for MySQL-Multi-AZ DB-Cluster unterstützen keine Replikation auf eine externe Zieldatenbank.

  • Multi-AZ-DB-Cluster von RDS for MySQL unterstützen nur die folgenden gespeicherten Systemprozeduren:

    • mysql.rds_rotate_general_log

    • mysql.rds_rotate_slow_log

    • mysql.rds_show_configuration

    Multi-AZ-DB-Cluster von RDS for MySQL unterstützen keine anderen gespeicherten Systemprozeduren. Informationen zu diesen Prozeduren finden Sie unter MySQL in Amazon RDS – SQL-Referenz.

  • Multi-AZ-DB-Cluster von RDS for PostgreSQL unterstützen die folgenden PostgreSQL-Erweiterungen nicht: aws_s3, pg_transport und pglogical.

  • Multi-AZ-DB-Cluster von RDS for PostgreSQL unterstützen nicht die Verwendung eines benutzerdefinierten DNS-Servers für ausgehenden Netzwerkzugriff.

  • Multi-AZ-DB-Cluster von RDS for PostgreSQL unterstützen keine logische Replikation.