Replikation mit Amazon Aurora My SQL - Amazon Aurora
Aurora-ReplikateReplikationsoptionenReplikationsleistungNeustart ohne Ausfallzeit (ZDR)Konfigurieren von ReplikationsfilternÜberwachung einer -Replikation

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

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:

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.

Neustart ohne Ausfallzeit (ZDR) für Amazon Aurora MySQL

Die Funktion „Neustart ohne Ausfallzeit“ (ZDR) kann einige oder alle aktiven Verbindungen zu DB-Instances während bestimmter Arten von Neustarts beibehalten. ZDR gilt für Neustarts, die Aurora automatisch durchführt, um Fehlerbedingungen zu beheben, beispielsweise wenn ein Replikat zu weit hinter der Quelle zurückbleibt.

Wichtig

Der ZDR-Mechanismus arbeitet auf Best-Effort-Basis. Die Aurora MySQL-Versionen, Instance-Klassen, Fehlerbedingungen, kompatible SQL-Operationen und andere Faktoren, die bestimmen, wo die ZDR gilt, können sich jederzeit ändern.

ZDR für Aurora MySQL 2.x erfordert Version 2.10 und höher. ZDR ist in allen Nebenversionen von Aurora MySQL 3.x verfügbar. In Aurora-MySQL-Version 2 und 3 ist der ZDR-Mechanismus standardmäßig aktiviert und Aurora verwendet den Parameter aurora_enable_zdr nicht.

Aurora berichtet über Aktivitäten auf der Ereignisseite im Zusammenhang mit dem Neustart ohne Ausfallzeiten. Aurora zeichnet ein Ereignis auf, wenn ein Neustart versucht wird, indem der Neustartmechanismus ohne Ausfallzeit verwendet wird. Dieses Ereignis gibt an, warum Aurora den Neustart durchführt. Aurora zeichnet dann ein anderes Ereignis auf, wenn der Neustart abgeschlossen ist. Dieses letzte Ereignis gibt an, wie lange der Prozess gedauert hat und wie viele Verbindungen während des Neustarts erhalten oder abgebrochen wurden. Sie können das Datenbankfehlerprotokoll einsehen, um weitere Details darüber zu erfahren, was während des Neustarts passiert ist.

Obwohl Verbindungen nach einem erfolgreichen ZDR-Vorgang intakt bleiben, werden einige Variablen und Funktionen neu initialisiert. Die folgenden Arten von Informationen werden durch einen Neustart, der durch den Neustart ohne Ausfallzeiten verursacht wird, nicht beibehalten:

  • Globale Variablen. Aurora stellt Sitzungsvariablen wieder her, stellt jedoch nach dem Neustart keine globalen Variablen wieder her.

  • Statusvariablen. Insbesondere wird der vom Engine-Status gemeldete Verfügbarkeitswert zurückgesetzt.

  • LAST_INSERT_ID.

  • In-Memory-auto_increment-Status für Tabellen. Der Status des automatischen In-Memory-Inkrements wird neu initialisiert. Weitere Informationen zu automatischen Inkrementwerten finden Sie im MySQL-Referenzhandbuch.

  • Diagnoseinformationen aus INFORMATION_SCHEMA- und PERFORMANCE_SCHEMA-Tabellen. Diese Diagnoseinformationen erscheinen auch in der Ausgabe von Befehlen wie SHOW PROFILE und SHOW PROFILES.

Die folgende Tabelle zeigt die Versionen, Instance-Rollen und andere Umstände, die bestimmen, ob Aurora den ZDR-Mechanismus beim Neustart von DB-Instances in Ihrem Cluster verwenden kann.

Aurora MySQL Version ZDR gilt für den Writer? ZDR gilt für Leser? ZDR ist immer aktiviert? Hinweise

2.x, niedriger als 2.10.0

Nein

Nein

N/A

ZDR ist für diese Versionen nicht verfügbar.

2.10.0–2.11.0

Ja

Ja

Ja

Aurora setzt alle Transaktionen zurück, die bei aktiven Verbindungen ausgeführt werden. Ihre Anwendung muss die Transaktionen erneut versuchen.

Aurora bricht alle Verbindungen ab, die TLS/SSL, temporäre Tabellen, Tabellensperren oder Benutzersperren verwenden.

2.11.1 und höher

Ja

Ja

Ja

Aurora setzt alle Transaktionen zurück, die bei aktiven Verbindungen ausgeführt werden. Ihre Anwendung muss die Transaktionen erneut versuchen.

Aurora bricht alle Verbindungen ab, die temporäre Tabellen, Tabellensperren oder Benutzersperren verwenden.

3.01–3.03

Ja

Ja

Ja

Aurora setzt alle Transaktionen zurück, die bei aktiven Verbindungen ausgeführt werden. Ihre Anwendung muss die Transaktionen erneut versuchen.

Aurora bricht alle Verbindungen ab, die TLS/SSL, temporäre Tabellen, Tabellensperren oder Benutzersperren verwenden.

3.04 und höher

Ja

Ja

Ja

Aurora setzt alle Transaktionen zurück, die bei aktiven Verbindungen ausgeführt werden. Ihre Anwendung muss die Transaktionen erneut versuchen.

Aurora bricht alle Verbindungen ab, die temporäre Tabellen, Tabellensperren oder Benutzersperren verwenden.

Konfigurieren von Replikationsfiltern mit Aurora MySQL

Sie können Replikationsfilter verwenden, um anzugeben, welche Datenbanken und Tabellen mit einem Lesereplikat repliziert werden. Replikationsfilter können Datenbanken und Tabellen in die Replikation einbeziehen oder sie von der Replikation ausschließen.

Im Folgenden finden Sie einige Anwendungsfälle für Replikationsfilter:

  • Reduzieren der Größe eines Lesereplikats. Mit Replikationsfiltern können Sie die Datenbanken und Tabellen ausschließen, die für das Lesereplikat nicht benötigt werden.

  • Ausschließen von Datenbanken und Tabellen von Lesereplikaten aus Sicherheitsgründen.

  • Replizieren verschiedener Datenbanken und Tabellen für spezifische Anwendungsfälle bei verschiedenen Lesereplikaten. Beispielsweise könnten Sie bestimmte Lesereplikate für Analysen oder Sharding verwenden.

  • Für einen DB-Cluster mit Read Replicas in verschiedenen AWS-Regionen, um unterschiedliche Datenbanken oder Tabellen in verschiedenen AWS-Regionen zu replizieren.

  • Um anzugeben, welche Datenbanken und Tabellen mit einem Aurora-MySQL-DB-Cluster repliziert werden, der als Replikat in einer eingehenden Replikationstopologie konfiguriert ist. Weitere Informationen zu dieser Konfiguration finden Sie unter Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation).

Einrichten der Parameter der Replikationsfilter für Aurora MySQL

Um Replikationsfilter zu konfigurieren, legen Sie die folgenden Parameter fest:

  • binlog-do-db – Repliziert Änderungen in die angegebenen Binärprotokolle. Wenn Sie diesen Parameter für einen Binärprotokoll-Quellcluster festlegen, werden nur die im Parameter angegebenen Binärprotokolle repliziert.

  • binlog-ignore-db – Repliziert keine Änderungen in die angegebenen Binärprotokolle. Wenn der binlog-do-db Parameter für einen Binärprotokoll-Quellcluster festgelegt ist, wird dieser Parameter nicht ausgewertet.

  • replicate-do-db – Repliziert Änderungen der angegebenen Datenbanken. Wenn Sie diesen Parameter für einen Binlog-Replikat-Cluster festlegen, werden nur die im Parameter angegebenen Datenbanken repliziert.

  • replicate-ignore-db – Repliziert keine Änderungen der angegebenen Datenbanken. Wenn der replicate-do-db Parameter für einen Binlog-Replikat-Cluster festgelegt ist, wird dieser Parameter nicht ausgewertet.

  • replicate-do-table – Repliziert Änderungen der angegebenen Tabellen. Wenn Sie diesen Parameter für ein Lesereplikat festlegen, werden nur die im Parameter angegebenen Tabellen repliziert. Wenn der replicate-ignore-db Parameter replicate-do-db oder festgelegt ist, stellen Sie außerdem sicher, dass Sie die Datenbank, die die angegebenen Tabellen enthält, in die Replikation mit dem Binlog-Replikat-Cluster einbeziehen.

  • replicate-ignore-table – Repliziert keine Änderungen der angegebenen Tabellen. Wenn der replicate-do-table Parameter für einen Binlog-Replikat-Cluster festgelegt ist, wird dieser Parameter nicht ausgewertet.

  • replicate-wild-do-table – Repliziert Tabellen basierend auf den angegebenen Namensmustern für Datenbanken und Tabellen. Die Platzhalterzeichen % und _ werden unterstützt. Wenn der replicate-ignore-db Parameter replicate-do-db oder festgelegt ist, stellen Sie sicher, dass Sie die Datenbank, die die angegebenen Tabellen enthält, in die Replikation mit dem Binlog-Replikat-Cluster einbeziehen.

  • replicate-wild-ignore-table – Repliziert keine Tabellen basierend auf den angegebenen Namensmustern für Datenbanken und Tabellen. Die Platzhalterzeichen % und _ werden unterstützt. Wenn der replicate-wild-do-table Parameter replicate-do-table oder für einen Binlog-Replikat-Cluster festgelegt ist, wird dieser Parameter nicht ausgewertet.

Die Parameter werden in der angegebenen Reihenfolge ausgewertet. Weitere Informationen zur Funktionsweise dieser Parameter finden Sie in der MySQL-Dokumentation:

Standardmäßig hat jeder dieser Parameter einen leeren Wert. Auf jedem Binärprotokoll-Cluster können Sie diese Parameter verwenden, um Replikationsfilter festzulegen, zu ändern und zu löschen. Wenn Sie einen dieser Parameter festlegen, trennen Sie die einzelnen Filter durch ein Komma voneinander.

Sie können die Platzhalterzeichen % und _ in den Parametern replicate-wild-do-table und replicate-wild-ignore-table verwenden. Der Platzhalter % entspricht einer beliebigen Anzahl von Zeichen, und der Platzhalter _ entspricht nur einem Zeichen.

Das binäre Protokollierungsformat der Quell-DB-Instance ist wichtig für die Replikation, da es den Datensatz der Datenänderungen bestimmt. Die Einstellung des Parameters binlog_format bestimmt, ob die Replikation zeilenbasiert oder anweisungsbasiert ist. Weitere Informationen finden Sie unter Konfigurieren der Aurora MySQL-Binärprotokollierung.

Anmerkung

Alle DDL-Anweisungen (Data Definition Language) werden unabhängig von der Einstellung binlog_format für die Quell-DB-Instance als Anweisungen repliziert.

Einschränkungen der Replikationsfilter für Aurora MySQL

Folgende Einschränkungen gelten für Replikationsfilter bei Aurora MySQL:

  • Replikationsfilter werden nur für Aurora MySQL Version 3 unterstützt.

  • Jeder Filterparameter für die Replikation hat ein Limit von 2.000 Zeichen.

  • Kommas werden in Replikationsfiltern nicht unterstützt.

  • Die Replikationsfilterung unterstützt keine XA-Transaktionen.

    Weitere Informationen finden Sie unter Einschränkungen bei XA-Transaktionen in der MySQL-Dokumentation.

Beispiele für Replikationsfilter bei Aurora MySQL

Um die Replikationsfilter für ein Lesereplikat zu konfigurieren, ändern Sie die Parameter der Replikationsfilter in der DB-Cluster-Parametergruppe, die dem Lesereplikat zugeordnet ist.

Anmerkung

Eine Standard-DB-Cluster-Parametergruppe kann nicht modifiziert werden. Erstellen Sie eine neue Parametergruppe und ordnen Sie diese der Lesereplika zu, wenn die Lesereplika eine Standardparametergruppe verwendet. Weitere Informationen zu DB-Cluster-Parametergruppen finden Sie unter Arbeiten mit Parametergruppen.

Sie können Parameter in einer DB-Cluster-Parametergruppe mithilfe der AWS Management Console-, AWS CLI- oder der RDS-API festlegen. Weitere Informationen zum Festlegen von Parametern finden Sie unter Ändern von Parametern in einer DB-Parametergruppe. Wenn Sie Parameter in einer Parametergruppe festlegen, verwenden alle DB-Cluster, die der Parametergruppe zugeordnet sind, diese Parametereinstellungen. Wenn Sie Parameter der Replikationsfilter in einer Parametergruppe festlegen, stellen Sie sicher, dass die Parametergruppe nur Replica-Clustern zugeordnet ist. Lassen Sie die Parameter der Replikationsfilter für Quell-DB-Instances leer.

In den folgenden Beispielen werden die Parameter mithilfe von festgeleg AWS CLI. Diese Beispiele legen ApplyMethod auf immediate fest, sodass die Parameteränderungen unmittelbar nach Abschluss des CLI-Befehls erfolgen. Wenn Sie möchten, dass eine ausstehende Änderung nach dem Neustart des Lesereplikats angewendet wird, legen Sie ApplyMethod auf pending-reboot fest.

In den folgenden Beispielen werden Replikationsfilter festgelegt:

Beispiel Einschließen von Datenbanken in die Replikation

Das folgende Beispiel schließt die Datenbanken mydb1 und mydb2 in die Replikation ein.

Für Linux, macOSoder Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"

Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
Beispiel Einschließen von Tabellen in die Replikation

Das folgende Beispiel schließt die Tabellen table1 und table2 in der Datenbank mydb1 in die Replikation ein.

Für Linux, macOSoder Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"

Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
Beispiel Einschließen von Tabellen in die Replikation mit Platzhalterzeichen

Das folgende Beispiel schließt Tabellen mit Namen, die mit order und return beginnen, in Datenbank mydb in die Replikation ein.

Für Linux, macOSoder Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"

Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
Beispiel Ausschließen von Datenbanken von der Replikation

Das folgende Beispiel schließt die Datenbanken mydb5 und mydb6 von der Replikation aus.

Für Linux, macOSoder Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"

Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate"
Beispiel Ausschließen von Tabellen von der Replikation

Das folgende Beispiel schließt die Tabellen table1 in Datenbank mydb5 und table2 in Datenbank mydb6 von der Replikation aus.

Für Linux, macOSoder Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"

Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
Beispiel Ausschließen von Tabellen von der Replikation mit Platzhalterzeichen

Das folgende Beispiel schließt Tabellen mit Namen, die mit order und return beginnen, in Datenbank mydb7 von der Replikation aus.

Für Linux, macOSoder Unix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Anzeigen der Replikationsfilter für ein Lesereplikat

Sie können die Replikationsfilter für ein Lesereplikat wie folgt anzeigen:

  • Überprüfen Sie die Einstellungen der Parameter der Replikationsfilter in der dem Lesereplikat zugeordneten Parametergruppe.

    Detaillierte Anweisungen finden Sie unter Anzeigen von Parameterwerten für eine DB-Parametergruppe.

  • Stellen Sie in einem MySQL-Client eine Verbindung zum Read-Replikat her und führen Sie dieSHOW REPLICA STATUS Anweisung aus.

    In der Ausgabe werden in den folgenden Feldern die Replikationsfilter für das Lesereplikat angezeigt:

    • Binlog_Do_DB

    • Binlog_Ignore_DB

    • Replicate_Do_DB

    • Replicate_Ignore_DB

    • Replicate_Do_Table

    • Replicate_Ignore_Table

    • Replicate_Wild_Do_Table

    • Replicate_Wild_Ignore_Table

    Weitere Informationen zu diesen Feldern finden Sie unter Überprüfen des Replikationsstatus in der MySQL-Dokumentation.

Ü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 ein Aurora-Replikat gegenüber der primären Instance Ihres Aurora MySQL-DB-Clusters zurückbleibt, indem Sie die Amazon CloudWatch AuroraReplicaLag-Metrik überwachen. Die AuroraReplicaLag-Metrik wird in jedem Aurora-Replikat aufgezeichnet.

Die primäre DB-Instance zeichnet auch die AuroraReplicaLagMinimum Amazon CloudWatch-Metriken AuroraReplicaLagMaximum und 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 aktuellen Wert für die Aurora-Replica-Verzögerung benötigen, können Sie die -AuroraReplicaLagMetrik in Amazon überprüfen CloudWatch. 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.