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.
Replikation mit Amazon Aurora My SQL
Die Aurora-MySQL-Replikationsfunktionen sind für die hohe Verfügbarkeit und Leistung Ihres Clusters entscheidend. Ein Aurora erleichtert das Erstellen und Skalieren von Clustern mit bis zu 15 Aurora-Replikaten.
Alle Replicas arbeiten mit denselben zugrunde liegenden Daten. Wenn einige Datenbank-Instances offline gehen, bleiben andere verfügbar, um die Verarbeitung von Abfragen fortzusetzen oder bei Bedarf als Writer zu übernehmen. Aurora verteilt Ihre schreibgeschützten Verbindungen automatisch auf mehrere Datenbank-Instances und hilft einem Aurora-Cluster, abfrageintensive Workloads zu unterstützen.
In den folgenden Themen finden Sie Informationen darüber, wie die Aurora-MySQL-Replikation funktioniert, und wie Sie die Replikationseinstellungen für beste Verfügbarkeit und Leistung anpassen.
Themen
- Verwendung von Aurora-Replicas
- Replikationsoptionen für Amazon Aurora MySQL
- Performance-Überlegungen zur Amazon Aurora MySQL-Replikation
- Neustart ohne Ausfallzeiten (ZDR) für Amazon Aurora My SQL
- Konfiguration von Replikationsfiltern mit Aurora My SQL
- Überwachung der Amazon Aurora MySQL-Replikation
- Replizieren von Amazon Aurora My SQL DB-Clustern auf AWS-Regionen
- Replikation zwischen Aurora und My SQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)
- Verwenden der GTID basierten Replikation
Verwendung von Aurora-Replicas
Aurora-Replicas sind unabhängige Endpunkte in einem Aurora-DB-Cluster, die die beste Methode für das Skalieren von Leseoperationen und Erhöhen der Verfügbarkeit darstellen. Es können bis zu 15 Aurora-Replikate über die Availability Zones verteilt werden, über die sich ein DB-Cluster innerhalb einer AWS-Region erstreckt. Obwohl das DB-Cluster-Volume aus mehreren Kopien der Daten in Ihrem DB-Cluster besteht, werden die Daten im Cluster-Volume als ein zusammengefasstes einzelnes logisches Volume der primären Instance und den Aurora Replicas im DB-Cluster dargestellt. Weitere Informationen über Aurora-Replicas finden Sie unter Aurora-Replikate.
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 Aurora MySQL-DB-Cluster geteilt wird, ist kein zusätzlicher Arbeitsaufwand erforderlich, um eine Kopie Ihrer Daten für jedes Aurora-Replica zu erstellen. Im Gegensatz dazu müssen MySQL-Read Replicas in einem einzelnen Thread alle Schreiboperationen aus der Quell-DB-Instance in ihrem lokalen Datenspeicher wiedergeben. Dies kann sich auf die Leistungsfähigkeit der unterstützten Lesevorgänge im Datenverkehr mit großem Volumen in Ihren MySQL-Lesereplikaten auswirken.
Mit Aurora MySQL wird beim Löschen eines Aurora-Replica der Instance-Endpunkt sofort entfernt und das Aurora-Replica vom Leser-Endpunkt entfernt. Wenn Anweisungen vorhanden sind, die auf dem Aurora-Replica ausgeführt werden, das gerade gelöscht wird, besteht eine Übergangsfrist von drei Minuten. Vorhandene Anweisungen können während der Nachfrist geordnet beendet werden. Nach Ablauf der Nachfrist wird das Aurora-Replikat geschlossen und gelöscht.
Wichtig
Aurora-Replicas für Aurora MySQL verwenden immer die standardmäßige Transaktionsisolationsebene REPEATABLE READ für Vorgänge in InnoDB-Tabellen. Sie können den Befehl SET TRANSACTION ISOLATION LEVEL verwenden, um die Transaktionsebene nur für die primäre Instance eines Aurora MySQL-DB-Clusters zu ändern. Diese Beschränkung vermeidet Sperren auf Benutzerebene in Aurora-Replicas und ermöglicht eine Skalierung der Aurora-Replicas, um tausende aktive Benutzerverbindungen bei gleichzeitig minimaler Replica-Verzögerung zu ermöglichen.
Anmerkung
Durch DDL-Anweisungen, die auf der primären Instance ausgeführt werden, können Datenbankverbindungen auf den verknüpften Aurora-Replikaten unterbrochen werden. Wenn eine Aurora-Replica-Verbindung aktiv ein Datenbankobjekt (z. B. eine Tabelle) verwendet und dieses Objekt auf der primären Instance mithilfe einer DDL-Anweisung geändert wird, führt das zu einer Unterbrechung der Aurora-Replica-Verbindung.
Anmerkung
Die Region China (Ningxia) unterstützt keine regionsübergreifenden Lesereplikate.
Replikationsoptionen für Amazon Aurora MySQL
Sie können eine Replikation zwischen allen folgenden Optionen einrichten:
-
Zwei unterschiedliche Aurora MySQL-DB-Cluster AWS-Regionen, indem eine regionsübergreifende Lesereplik eines Aurora MySQL-DB-Clusters erstellt wird.
Weitere Informationen finden Sie unter Replizieren von Amazon Aurora My SQL DB-Clustern auf AWS-Regionen.
-
Zwei Aurora MySQL-DB-Cluster in demselben AWS-Region, wobei die MySQL-Binärprotokollreplikation (Binlog) verwendet wird.
Weitere Informationen finden Sie unter Replikation zwischen Aurora und My SQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation).
-
Eine RDS for MySQL-DB-Instance als Quelle und ein Aurora MySQL-DB-Cluster, indem Sie ein Aurora-Read Replica einer RDS for MySQL-DB-Instance erstellen.
Sie können diesen Ansatz verwenden, um bestehende und laufende Datenänderungen in Aurora MySQL während der Migration zu Aurora zu bringen. Weitere Informationen finden Sie unter Migrieren von Daten von einer RDS for My SQL DB-Instance zu einem Amazon Aurora My SQL DB-Cluster mithilfe einer Aurora-Read Replica.
Sie können diesen Ansatz auch verwenden, um die Skalierbarkeit von Leseabfragen für Ihre Daten zu erhöhen. Sie tun dies, indem Sie die Daten mit einer oder mehreren DB-Instances in einem schreibgeschützten Aurora MySQL-Cluster abfragen. Weitere Informationen finden Sie unter Skalierung von Lesevorgängen für Ihre My SQL Database mit Amazon Aurora.
-
Ein Aurora MySQL-DB-Cluster in einem AWS-Region und bis zu fünf Aurora MySQL-DB-Cluster mit Schreibschutz in verschiedenen Regionen, indem eine globale Aurora-Datenbank erstellt wird.
Sie können eine Aurora globale Datenbank verwenden, um Anwendungen mit einem weltweiten Fußabdruck zu unterstützen. Der primäre Aurora MySQL-DB-Cluster verfügt über eine Writer-Instance und bis zu 15 Aurora Replikate. Die schreibgeschützten sekundären Aurora MySQL-DB-Cluster können jeweils aus bis zu 16 Aurora Replikaten bestehen. Weitere Informationen finden Sie unter Verwenden der Amazon Aurora Global Database.
Anmerkung
Durch einen Neustart der primären Instance eines Amazon Aurora-DB-Clusters werden auch automatisch die Aurora-Replicas für diesen DB-Cluster neu gestartet, um einen Einstiegspunkt wiederherzustellen, der die Lese-/Schreibkonsistenz innerhalb des DB-Clusters hinweg gewährleistet.
Performance-Überlegungen zur Amazon Aurora MySQL-Replikation
Die folgenden Funktionen helfen Ihnen bei der Optimierung der Leistung der Aurora MySQL-Replikation.
Die Funktion Replica-Protokollkompression reduziert automatisch die Netzwerkbandbreite für Replikationsbenachrichtigungen. Weil jede Benachrichtigung an alle Aurora-Replicas gesendet wird, sind die Vorteile bei umfangreicheren Clustern größer. Diese Funktion beinhaltet einen gewissen CPU-Overhead im Schreiber-Knoten, um die Kompression durchzuführen. In Aurora MySQL Version 2 und Version 3 ist sie immer aktiviert.
Die Funktion Binärprotokollfilterung reduziert automatisch die Netzwerkbandbreite für Replikationsbenachrichtigungen. Da Aurora-Replicas die in den Replikationsbenachrichtigungen enthaltene Binärprotokollinformation nicht verwenden, sind diese Daten in den an diese Knoten gesendeten Benachrichtigungen nicht enthalten.
In Aurora MySQL Version 2 steuern Sie diese Funktion durch eine Änderung des aurora_enable_repl_bin_log_filtering-Parameters. Dieser Parameter ist standardmäßig aktiviert. Da diese Optimierung transparent sein soll, können Sie diese Einstellung nur während der Diagnose oder Fehlersuche bei Problemen im Zusammenhang mit der Replikation deaktivieren. Beispielsweise können Sie so das Verhalten eines älteren Aurora MySQL-Clusters anzupassen, bei dem diese Funktion nicht verfügbar war.
Die Binlog-Filterung ist in Aurora MySQL Version 3 immer aktiviert.
Überwachung der Amazon Aurora MySQL-Replikation
Skalieren von Lesevorgängen und hohe Verfügbarkeit hängen von der minimalen Verzögerungszeit ab. Sie können überwachen, wie weit eine Aurora Replica hinter der primären Instance Ihres Aurora MySQL-DB-Clusters zurückbleibt, indem Sie die CloudWatch AuroraReplicaLag Amazon-Metrik überwachen. Die AuroraReplicaLag-Metrik wird in jedem Aurora-Replikat aufgezeichnet.
Die primäre DB-Instance zeichnet auch die AuroraReplicaLagMaximum und AuroraReplicaLagMinimum CloudWatch Amazon-Metriken auf. Die AuroraReplicaLagMaximum-Metrik zeichnet die maximale Verzögerung zwischen der primären DB-Instance und jedem Aurora-Replikat im DB-Cluster auf. Die AuroraReplicaLagMinimum-Metrik zeichnet die minimale Verzögerung zwischen der primären DB-Instance und jedem Aurora-Replikat im DB-Cluster auf.
Wenn Sie den aktuellsten Wert für Aurora Replica-Lag benötigen, können Sie die AuroraReplicaLag Metrik in Amazon CloudWatch überprüfen. Die Aurora-Replica-Verzögerung wird auch für jedes Aurora-Replikat Ihres DB-Clusters von Aurora MySQL in der information_schema.replica_host_status-Tabelle aufgezeichnet. Weitere Informationen zu dieser Tabelle finden Sie unter information_schema.replica_host_status.
Weitere Informationen zur Überwachung von RDS-Instances und CloudWatch -Metriken finden Sie unterÜberwachung von Metriken in einem Amazon-Aurora-Cluster.
