Replikation mit Amazon Aurora

Es gibt mehrere Replikations-Optionen für Aurora. Jeder Aurora-DB-Cluster verfügt über eine integrierte Replikation zwischen mehreren DB-Instances im selben Cluster. Sie können auch die Replikation mit Ihrem Aurora-Cluster als Quelle oder Ziel einrichten. Wenn Sie Daten in oder aus einem Aurora-Cluster replizieren, können Sie zwischen integrierten Funktionen wie Aurora globalen Datenbanken oder den herkömmlichen Replikationsmechanismen für die MySQL- oder PostgreSQL-DB-Engines wählen. Sie können die geeigneten Optionen auswählen, je nachdem, welche die richtige Kombination aus Hochverfügbarkeit, Komfort und Leistung für Ihre Anforderungen bietet. In den folgenden Abschnitten wird erläutert, wie und wann Sie die jeweilige Technik wählen.

Aurora-Replikate

Wenn Sie eine zweite, dritte und so weiter DB-Instance in einem bereitgestellten Aurora-DB-Cluster erstellen, wird Aurora automatisch die Replikation von der Writer-DB-Instance zu allen anderen DB-Instances einrichten. Diese anderen DB-Instances sind schreibgeschützt und werden als Aurora-Replicas bezeichnet. Wir bezeichnen sie auch als Reader-Instances, wenn wir besprechen, wie Sie Writer- und Reader-DB-Instances innerhalb eines Clusters kombinieren können.

Aurora-Replicas haben zwei Hauptzwecke. Sie können über sie Abfragen stellen, um die Lesevorgänge für Ihre Anwendung zu skalieren. In der Regel tun Sie dies, indem Sie eine Verbindung zum Reader-Endpunkt des Clusters herstellen. Auf diese Weise kann Aurora die Last für schreibgeschützte Verbindungen auf so viele Aurora-Replicas verteilen, wie Sie im Cluster haben. Aurora-Replicas tragen auch dazu bei, die Verfügbarkeit zu erhöhen. Wenn die Writer-Instance in einem Cluster nicht verfügbar ist, stuft Aurora automatisch eine der Reader-Instances hoch, um ihren Platz als neuer Autor einzunehmen.

Ein Aurora-DB-Cluster kann bis zu 15 Aurora-Replicas enthalten. Die Aurora-Replikate können über die Availability Zones verteilt werden, über die sich ein DB-Cluster innerhalb einer AWS -Region erstreckt.

Die Daten in Ihrem DB-Cluster haben ihre eigenen Hochverfügbarkeits- und Zuverlässigkeitsfunktionen, unabhängig von den DB-Instances im Cluster. Wenn Sie mit den Aurora-Speicherfunktionen nicht vertraut sind, lesen Sie Übersicht über Amazon-Aurora-Speicher. Das DB-Cluster-Volume besteht physisch aus mehreren Kopien der Daten für den DB-Cluster. Die primäre Instance und die Aurora-Replicas im DB-Cluster sehen die Daten im Cluster-Volume als ein einziges logisches Volume.

Daher geben alle Aurora-Replikate die gleichen selben Daten als Abfrageergebnisse bei minimaler Replikatsverzögerung zurück. Diese Verzögerung beträgt in der Regel sehr viel weniger als 100 Millisekunden nach dem Schreiben einer Aktualisierung durch die primäre Instance. Die Replica-Verzögerung variiert in Abhängigkeit vom Veränderungsgrad in der Datenbank. In den Zeitabschnitten, in denen sehr viele Schreibvorgänge in der Datenbank durchgeführt werden, könnte es zu einer erhöhten Replica-Verzögerung kommen.

Anmerkung

Aurora Replica wird neu gestartet, wenn die Kommunikation mit der Writer-DB-Instance in den folgenden Aurora-PostgreSQL-Versionen länger als 60 Sekunden unterbrochen wird:

• 14.6 und ältere Versionen

• 13.9 und ältere Versionen

• 12.13 und ältere Versionen

• Alle Versionen von Aurora PostgreSQL 11

Aurora Replicas funktionieren für das Skalieren von Lesevorgängen, da sie in Ihrem Cluster-Volume vollständig für Lesevorgänge bereit stehen. Schreibvorgänge werden von der primären Instance verwaltet. Da das Cluster-Volume zwischen allen Instances in Ihrem DB-Cluster geteilt wird, bedeutet es nur einen geringen Aufwand, um eine Kopie der Daten für die einzelnen Aurora-Replicas zu replizieren.

Sie können Aurora Replicas als Failover-Vorgaben verwenden, um die Verfügbarkeit zu erhöhen. Das heißt, wenn die primäre Instance ausfällt, wird ein Aurora-Replikat zur primären Instance heraufgestuft. Es gibt dann eine kurze Unterbrechung, während der Lese- und Schreibanfragen an die primäre Instance mit einer Ausnahme fehlschlagen.

Die Hochstufung einer Aurora-Replica per Failover ist eine viel schnellere Methode als die Neuerstellung der primären Instance. Wenn Ihr Aurora-DB-Cluster keine Aurora-Replikate enthält, steht Ihr DB-Cluster während der Wiederherstellung Ihrer DB-Instance nach dem Ausfall nicht zur Verfügung.

Bei einem Failover werden möglicherweise einige der Aurora-Replikate je nach Version der DB-Engine neu gestartet. In Aurora MySQL 2.10 und höher startet Aurora nur die Writer-DB-Instance und das Failover-Ziel während eines Failovers neu. Informationen zum Neustartverhalten verschiedener Aurora-DB-Engine-Versionen finden Sie unter Neustart eines Amazon Aurora DB-Clusters oder einer Amazon Aurora DB-Instance. Hinweise dazu, was mit Seitencaches beim Neustart oder Failover geschieht, finden Sie unterÜberlebensfähiger Seiten-Cache.

Für Szenarien mit hoher Verfügbarkeit empfehlen wir Ihnen, mindestens ein Aurora-Replikat zu erstellen. Diese sollten dieselbe DB-Instance-Class haben wie die primäre Instance und in verschiedenen Availability Zones für Ihren Aurora-DB-Cluster liegen. Weitere Informationen über Aurora-Replikate als Failover-Ziele finden Sie unter Fehlertoleranz für einen Aurora-DB-Cluster.

Sie können keine verschlüsselte Aurora-Replica für einen unverschlüsselten Aurora-DB-Cluster erstellen. Sie können keine unverschlüsselte Aurora-Replica für einen verschlüsselten Aurora-DB-Cluster erstellen.

Tipp

Sie können Aurora-Replicas innerhalb eines Aurora-Clusters als Ihre einzige Form der Replikation verwenden, um Ihre Daten hochverfügbar zu halten. Sie können die integrierte Aurora-Replikation auch mit den anderen Arten der Replikation kombinieren. Dies kann dazu beitragen, ein zusätzliches Maß an hoher Verfügbarkeit und geografischer Verteilung Ihrer Daten zu gewährleisten.

Details zum Erstellen von Aurora-Replicas finden Sie unter Hinzufügen von Aurora-Replicas zu einem DB-Cluster.

Replikation mit Aurora MySQL

Zusätzlich zu Aurora-Replicas haben Sie die folgenden Möglichkeiten für Replikationen mit Aurora MySQL:

• Aurora MySQL-DB-Cluster in verschiedenen - AWS Regionen.

  • Sie können Daten über mehrere Regionen mithilfe einer Aurora globalen Datenbank replizieren. Details hierzu finden Sie unter Hohe Verfügbarkeit über AWS -Regionen hinweg mit globalen Aurora-Datenbanken.

  • Sie können ein Aurora-Lesereplikat eines Aurora MySQL-DB-Clusters in einer anderen - AWS Region erstellen, indem Sie die MySQL-Binlog-Replikation (Binärprotokoll) verwenden. Jeder Cluster kann über bis zu fünf auf diese Weise erstellte Lesereplikate verfügen, die sich jeweils in einer anderen Region befinden.

• Zwei Aurora-MySQL-DB Cluster in der gleichen Region, indem Sie mit dem MySQL-Binärprotokoll (binlog) eine Replikation einrichten.

• Eine RDS-for-MySQL-DB-Instance als Datenquelle und ein Aurora-MySQL-DB-Cluster, indem Sie ein Aurora-Lesereplikat einer RDS-for-MySQL-DB-Instance erstellen. Üblicherweise verwenden Sie diese Methode eher bei Migrationsvorgängen nach Aurora MySQL als für die fortlaufende Replikation.

Weitere Informationen zur Replikation mit Aurora MySQL finden Sie unter Replikation mit Amazon Aurora My SQL.

Replikation mit Aurora PostgreSQL

Zusätzlich zu Aurora-Replicas haben Sie die folgenden Möglichkeiten für Replikationen mit Aurora PostgreSQL:

• Ein primärer Aurora-DB-Cluster in einer Region und bis zu fünf schreibgeschützte sekundäre DB-Cluster in verschiedenen Regionen unter Verwendung einer globalen Aurora-Datenbank. Aurora PostgreSQL unterstützt keine regionsübergreifenden Aurora-Replikate. Sie können jedoch die globale Aurora-Datenbank verwenden, um die Lesefunktionen Ihres DB-Clusters von Aurora PostgreSQL auf mehr als eine AWS Region zu skalieren und die Verfügbarkeitsziele zu erreichen. Weitere Informationen finden Sie unter Verwenden von Amazon Aurora Global Databases.

• Zwei Aurora-PostgreSQL-DB-Cluster in derselben Region, indem die logische Replikationsfunktion von PostgreSQL verwendet wird.

• Eine RDS-for-PostgreSQL-DB-Instance als Datenquelle und ein Aurora-PostgreSQL-DB-Cluster, indem ein Aurora-Lesereplikat einer RDS-for-PostgreSQL-DB-Instance erstellt wird. Üblicherweise verwenden Sie diese Methode eher bei Migrationsvorgängen nach Aurora PostgreSQL als für die fortlaufende Replikation.

Weitere Informationen zur Replikation mit Aurora PostgreSQL finden Sie unter Replikation mit Amazon Aurora PostgreSQL.