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.

Multi-AZ-DB-Cluster-Bereitstellungen für Amazon RDS

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 zur Version und regionalen Verfügbarkeit von Amazon RDS mit Multi-AZ-DB-Clustern finden Sie unterUnterstützte Regionen und DB-Engines für Multi-AZ-DB-Cluster in Amazon RDS.

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,db.m6id,db.m6idn,,db.r5d,db.r6gd, und db.x2iedndb.r6id, unddb.r6idn. db.c6gd

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

Multi-AZ-DB-Cluster-Architektur

Bei einem Multi-AZ-DB-Cluster RDS repliziert Amazon 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 bei Ihrer Writer-DB-Instance ein Ausfall auftritt, RDS verwaltet es den Failover zu einer der Reader-DB-Instances. RDStut dies auf der Grundlage der Reader-DB-Instance, die den letzten Änderungsdatensatz hat.

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. In der RDS Konsole werden die Availability Zone der Writer-DB-Instance und die Availability Zones der Reader-DB-Instances angezeigt. Sie können auch den describe-db-clustersCLIBefehl oder die escribeDBClustersAPID-Operation verwenden, um diese Informationen zu finden.

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 DB-Cluster-Parametergruppen für Multi-AZ-DB-Cluster.

RDSProxy 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 der RDS Proxy alle Operationen für eine Transaktion mithilfe einer zugrunde liegenden Datenbankverbindung aus. RDSProxy 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 unterAmazon RDS Proxy verwenden.

Um einen Proxy für einen Multi-AZ-DB-Cluster einzurichten, wählen Sie beim Erstellen des Clusters die Option Create an RDS Proxy 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Überwachung von Amazon RDS Amazon 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.

RDSBei My SQL Multi-AZ DB-Clustern 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.

RDSBei SQL Postgre-Multi-AZ-DB-Clustern hängt die Failover-Zeit von der niedrigsten 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 auslösen, wenn die Replikatverzögerung einen bestimmten Zeitraum überschreitet, finden Sie unter. Tutorial: Erstellen eines CloudWatch Amazon-Alarms für Multi-AZ-DB-Cluster-Replikatverzögerungen für Amazon RDS

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:

Minderung der Replikatverzögerung

Bei Multi-AZ-DB-Clustern RDS für My SQL und RDS für Postgre können Sie die Replikatverzögerung verringernSQL, 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 Flusskontrolle mit RDS für My SQL und für Postgre. RDS SQL

Verringerung der Replikatverzögerung durch Flusskontrolle für for My RDS SQL

Wenn Sie RDS für My SQL Multi-AZ DB-Cluster verwenden, ist die Flusskontrolle standardmäßig mithilfe des dynamischen Parameters aktiviert. rpl_semi_sync_master_target_apply_lag 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)

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

Minderung von Replikatverzögerungen mit Flusssteuerung für Postgre RDS SQL

Wenn Sie SQL Multi-AZ-DB-Cluster RDS für Postgre verwenden, wird die Flusskontrolle 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 Ablaufsteuerung einen SQL Postgre-Prozess drosselt, weist das Extension Warteereignis 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 Flusssteuerung kann den meisten Workloads zur Online-Transaktionsverarbeitung (OLTP) zugute kommen, bei denen es zu kurzen, aber sehr gleichzeitigen Transaktionen kommt. 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 shared_preload_libraries entfernen und Ihre DB-Instance neu starten.

Snapshots von Multi-AZ-DB-Clustern

Amazon RDS erstellt und speichert automatische Backups Ihres Multi-AZ-DB-Clusters während des konfigurierten Backup-Fensters. RDSerstellt einen Speichervolume-Snapshot Ihres DB-Clusters und sichert dabei den gesamten Cluster und nicht nur einzelne Instances.

Sie können auch manuelle Backups Ihres Multi-AZ-DB-Clusters erstellen. Für sehr langfristige Backups sollten Sie erwägen, die Snapshot-Daten nach Amazon S3 zu exportieren. Weitere Informationen finden Sie unter Erstellen eines Multi-AZ-DB-Cluster-Snapshots für Amazon RDS.

Sie können einen Multi-AZ-DB-Cluster auf einen bestimmten Zeitpunkt wiederherstellen, wodurch ein neuer Multi-AZ-DB-Cluster erstellt wird. Detaillierte Anweisungen finden Sie unter Wiederherstellen eines Multi-AZ-DB-Clusters zu einer bestimmten Zeit.

Alternativ können Sie einen Multi-AZ-DB-Cluster-Snapshot in einer Single-AZ-Bereitstellung oder einer Multi-AZ-DB-Instance-Bereitstellung wiederherstellen. Detaillierte Anweisungen finden Sie unter Wiederherstellen über einen Snapshot eines Multi-AZ-DB-Clusters in einer DB-Instance.