Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation) - Amazon Aurora
Einrichten einer Replikation mit einem MySQL- oder einem anderen Aurora-DB-ClusterSynchronisierung von Passwörtern zwischen Replikationsquelle und -zielAnhalten einer Replikation zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-ClusterVerwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-DatenbankOptimieren der binären Protokollreplikation Einrichten eines erweiterten Binärprotokolls

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.

Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)

Da Amazon Aurora MySQL mit MySQL kompatibel ist, können Sie eine Replikation zwischen einer MySQL-Datenbank und einem Amazon Aurora MySQL-DB-Cluster einrichten. Bei diesem Replikationstyp wird die binäre MySQL-Protokoll-Replikation verwendet, die auch als Binärprotokoll-Replikation bezeichnet wird. Wenn Sie die binäre Protokollreplikation mit Aurora verwenden, sollte Ihre MySQL-Datenbank MySQL-Version 5.5 oder höher verwenden. Sie können eine Replikation einrichten, bei der Ihr Aurora MySQL DB-Cluster die Replikationsquelle oder das Replica ist. Sie können mit einer Amazon RDS-MySQL-DB-Instance, einer MySQL-Datenbank außerhalb von Amazon RDS oder einem anderen Aurora MySQL-DB-Cluster replizieren.

Anmerkung

Sie können die an bestimmte Arten von Aurora-Clustern gesendete oder davon empfangene Binlog-Replikation nicht verwenden. Insbesondere ist die Binlog-Replikation nicht für Aurora Serverless v1-Cluster verfügbar. Wenn die Anweisungen SHOW MASTER STATUS und SHOW SLAVE STATUS (Aurora-MySQLVersion 2) oder SHOW REPLICA STATUS (Aurora-MySQL-Version 3) keine Ausgabe zurückgeben, überprüfen Sie, ob der von Ihnen verwendete Cluster die Binlog-Replikation unterstützt.

In Aurora MySQL Version 3 können Sie mit der binären Protokollreplikation nicht in eine mysql-Systemdatenbank replizieren. In Aurora MySQL Version 3 werden keine Passwörter und Konten durch die binäre Protokollreplikation repliziert. Daher werden Data Control Language (DCL)-Anweisungen wie CREATE USER, GRANT und REVOKE nicht repliziert.

Sie können eine Replikation auch mit einer RDS-for-MySQL-DB-Instance oder einem Aurora-MySQL-DB-Cluster in einer anderen AWS-Region vornehmen. Wenn Sie eine Replikation durchführen AWS-Regionen, stellen Sie sicher, dass Ihre DB-Cluster und DB-Instances öffentlich zugänglich sind. Wenn sich die Aurora MySQL-DB-Cluster in privaten Subnetzen in Ihrer VPC befinden, verwenden Sie VPC-Peering zwischen den AWS-Regionen. Weitere Informationen finden Sie unter Ein DB-Cluster in einer VPC, auf den eine EC2-Instanz in einer anderen VPC zugreift.

Wenn Sie die Replikation zwischen einem Aurora MySQL-DB-Cluster und einem Aurora MySQL-DB-Cluster in einem anderen konfigurieren möchten AWS-Region, können Sie einen Aurora MySQL-DB-Cluster als Read Replica in einem anderen als AWS-Region dem Quell-DB-Cluster erstellen. Weitere Informationen finden Sie unter Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg.

Mit Auror-MySQL-Version 2 und 3 können Sie eine Replikation zwischen Aurora MySQL und einer externen Quelle oder einem Ziel durchführen, die bzw. das globale Transaktionskennungen (Global Transaction Identifiers, GTIDs) für die Replikation verwendet. Stellen Sie sicher, dass die Einstellungen der GTID-bezogenen Parameter im Aurora MySQL-DB-Cluster mit dem GTID-Staus der externen Datenbank kompatibel sind. Weitere Informationen zur Vorgehensweise finden Sie unter Verwenden der GTID-basierten Replikation für Amazon Aurora MySQL. In Aurora-MySQL-Version 3.01 und höher können Sie auswählen, wie GTIDs Transaktionen zugewiesen werden, die von einer Quelle repliziert werden, die keine GTIDs verwendet. Informationen zur gespeicherten Prozedur, die diese Einstellung steuert, finden Sie unter mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL Version 3).

Warnung

Wenn Sie zwischen Aurora MySQL und MySQL replizieren, dürfen Sie nur InnoDB-Tabellen verwenden. Wenn Sie MyISAM-Tabellen replizieren möchten, müssen Sie diese mit dem folgenden Befehl in das InnoDB-Format konvertieren, bevor Sie die Replikation einrichten. 

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

Einrichten einer Replikation mit einem MySQL- oder einem anderen Aurora-DB-Cluster

Das Einrichten einer MySQL-Replikation mit Aurora MySQL umfasst die folgenden Schritte, die ausführlich erklärt werden:

1. Aktivieren der Binärprotokollierung für die Replikationsquelle

2. Beibehaltung der Binärprotokolle für die Replikationsquelle, bis diese nicht mehr erforderlich sind

3. Erstellen eines Snapshots oder Dumps Ihrer Replikationsquelle

4. Laden des Snapshots oder Dumps in das Replikat-Ziel

5. Erstellen Sie einen Replikationsbenutzer auf Ihrer Replikationsquelle

6. Aktivieren der Replikation für das Replikat-Ziel

7. Überwachen Ihres Replikats

1. Aktivieren der Binärprotokollierung für die Replikationsquelle

Im Folgenden finden Sie die Anweisungen zum Aktivieren der Binärprotokollierung an der Replikationsquelle für Ihre Datenbank-Engine.

2. Beibehaltung der Binärprotokolle für die Replikationsquelle, bis diese nicht mehr erforderlich sind

Wenn Sie die binäre MySQL-Protokollreplikation verwenden, verwaltet Amazon RDS den Replikationsvorgang nicht. Daher müssen Sie sicherstellen, dass die Binärprotokolldateien an Ihre Replikationsquelle so lange aufbewahrt werden, bis die Änderungen auf das Replica angewandt wurden. Durch diese Pflege können Sie Ihre Quelldatenbank im Fall eines Ausfalls wiederherstellen.

Verwenden Sie folgende Anweisungen zur Beibehaltung von Binärprotokollen für Ihre Datenbank-Engine.

3. Erstellen eines Snapshots oder Dumps Ihrer Replikationsquelle

Sie verwenden einen Snapshot oder Dump Ihrer Replikationsquelle, um die Baseline-Kopie Ihrer Daten in Ihr Replica zu kopieren und starten die Replikation dann ab diesem Punkt.

Verwenden Sie folgende Anweisungen zum Erstellen eines Snapshots oder Dumps der Replikationsquelle für Ihre Datenbank-Engine.

4. Laden des Snapshots oder Dumps in das Replikat-Ziel

Wenn Sie Daten aus einem Dump einer Amazon RDS-externen MySQL-Datenbank laden möchten, können Sie eine EC2-Instance erstellen, die Dumpdateien dorthin kopieren und die Daten anschließend aus dieser EC2-Instance in das DB-Cluster oder die DB-Instance laden. Bei Verwendung dieses Ansatzes können Sie die Dumpdateien komprimieren, bevor Sie sie in eine EC2-Instance kopieren, um Netzwerkkosten zu minimieren, die in Verbindung mit dem Kopieren von Dateien nach Amazon RDS entstehen. Sie können die Dumpdatei oder -dateien auch verschlüsseln, um sie beim Übermitteln im Netzwerk zu schützen.

Verwenden Sie folgende Anweisungen, um den Snapshot Ihrer Replikationsquelle in das Replikat-Ziel für Ihre Datenbank-Engine zu laden.

5. Erstellen Sie einen Replikationsbenutzer auf Ihrer Replikationsquelle

Erstellen Sie eine Benutzer-ID an der Quelle, die ausschließlich für die Replikation verwendet wird. Das folgende Beispiel bezieht sich auf RDS für MySQL oder externe MySQL-Quelldatenbanken.

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

Für Aurora MySQL-Quelldatenbanken ist der skip_name_resolve DB-Cluster-Parameter auf 1 (ON) gesetzt und kann nicht geändert werden. Sie müssen also eine IP-Adresse für den Host anstelle eines Domainnamens verwenden. Weitere Informationen finden Sie unter skip_name_resolve in der MySQL-Dokumentation.

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

Der Benutzer benötigt die Berechtigungen REPLICATION CLIENT und REPLICATION SLAVE. Gewähren Sie dem Benutzer diese Berechtigungen.

Wenn die Replikation verschlüsselt durchgeführt werden muss, fordern Sie für den Replikationsbenutzer eine SSL-Verbindung an. Sie können beispielsweise eine der folgenden Anweisungen verwenden, um SSL-Verbindungen für das Benutzerkonto vorzuschreiben. repl_user

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
Anmerkung

Wenn REQUIRE SSL nicht angegeben wird, kann die Replikationsverbindung ohne entsprechende Meldung auf eine unverschlüsselte Verbindung zurückgesetzt werden.

6. Aktivieren der Replikation für das Replikat-Ziel

Bevor Sie die Replikation aktivieren, empfehlen wir, manuell einen Snapshot des Aurora-MySQL-DB-Clusters oder des RDS for MySQL-DB-Instance Replica-Ziels zu erstellen. Wenn ein Problem auftritt und Sie den Replikationsvorgang mit dem DB-Cluster oder dem DB-Instance-Replica-Ziel wieder einrichten müssen, können Sie das DB-Cluster bzw. die DB-Instance aus diesem Snapshot wiederherstellen, anstatt erneut Daten in das Replica-Ziel zu importieren.

Verwenden Sie folgende Anweisungen zum Aktivieren der Replikation für Ihre Datenbank-Engine.

Wenn die Replikation fehlschlägt, kann dies zu einem starken Anstieg der unbeabsichtigten I/O auf dem Replikat führen, was die Leistung beeinträchtigen kann. Wenn die Replikation fehlschlägt oder nicht mehr benötigt wird, können Sie das gespeicherte Verfahren mysql.rds_reset_external_master (Aurora-MySQL-Version 2) oder mysql.rds_reset_external_source (Aurora MySQL Version 3) zum Entfernen der Replikationskonfiguration durchführen.

Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica

In der Aurora MySQL-Version 3.04 und höher können Sie die Replikation starten und dann an einem bestimmten Ort in der Binär-Protokolldatei mit der gespeicherten mysql.rds_start_replication_until (Aurora-MySQL-Version 3)-Prozedur anhalten.

Starten Sie die Replikation für ein Lesereplikat und stoppen Sie die Replikation an einer bestimmten Position wie folgt:

  1. Stellen Sie über einen MySQL-Client als Masterbenutzer eine Verbindung zum Replikat-Aurora-MySQL-DB-Cluster her.

  2. Führen Sie die gespeicherte Prozedur mysql.rds_start_replication_until (Aurora-MySQL-Version 3) aus.

    Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die Position 120 in der Binärprotokolldatei mysql-bin-changelog.000777 erreicht wird. Beispiel: In einem Szenario der Notfallwiederherstellung liegt die Position 120 unmittelbar vor der Katastrophe.

    call mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

Die Replikation stoppt automatisch, sobald der Stopppunkt erreicht ist. Das folgende RDS-Ereignis wird generiert: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Wenn Sie die GTID-basierte Replikation verwenden, nutzen Sie die gespeicherte Prozedur mysql.rds_start_replication_until_gtid (Aurora-MySQL-Version 3) anstelle der gespeicherten Prozedur mysql.rds_start_replication_until (Aurora-MySQL-Version 3). Weitere Informationen zu GTID-basierten Replikationen finden Sie unter Verwenden der GTID-basierten Replikation für Amazon Aurora MySQL.

7. Überwachen Ihres Replikats

Wenn Sie eine MySQL-Replikation mit einem Aurora MySQL-DB-Cluster eingerichtet haben, müssen Sie Failover-Ereignisse für den Aurora MySQL-DB-Cluster überwachen, wenn dieser ein Replica-Ziel ist. Im Falle eines Failovers kann dann das DB-Cluster (das Replica-Ziel) auf einem neuen Host mit einer anderen Netzwerkadresse erneut erstellt werden. Weitere Informationen zum Überwachen von Failover-Ereignissen finden Sie unter Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen.

Sie können außerdem überwachen, wie weit das Replica-Ziel hinter der Replikationsquelle zurückliegt, indem Sie eine Verbindung zum Replica-Ziel herstellen und den Befehl SHOW SLAVE STATUS (Aurora-MySQL-Version 2) oder SHOW REPLICA STATUS (Aurora-MySQL-Version 3) ausführen. In der Befehlsausgabe wird im Feld Seconds Behind Master angezeigt, wie weit das Replica-Ziel hinter der Quelle zurückliegt.

Synchronisierung von Passwörtern zwischen Replikationsquelle und -ziel

Wenn Sie Benutzerkonten und Kennwörter auf der Replikationsquelle mithilfe von SQL-Anweisungen ändern, werden diese Änderungen automatisch auf das Replikationsziel repliziert.

Wenn Sie die AWS Management Console, die oder die RDS-API verwenden AWS CLI, um das Master-Passwort für die Replikationsquelle zu ändern, werden diese Änderungen nicht automatisch auf das Replizierungsziel repliziert. Wenn Sie den Master-Benutzer und das Master-Kennwort zwischen dem Quell- und dem Zielsystem synchronisieren möchten, müssen Sie die gleiche Änderung auf dem Replikationsziel selbst vornehmen.

Anhalten einer Replikation zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster

Folgen Sie diesen im folgenden Verlauf detailliert beschriebenen Schritten, um eine binäre Protokollreplikation mit einer MySQL-DB-Instance, einer externen MySQL-Datenbank oder einem anderen Aurora-DB-Cluster anzuhalten.

1. Anhalten der binären Protokollreplikation für das Replikat-Ziel

2. Deaktivieren der Binärprotokollierung für die Replikationsquelle

1. Anhalten der binären Protokollreplikation für das Replikat-Ziel

Im Folgenden finden Sie die Anweisungen zum Anhalten der binären Protokollreplikation für Ihre Datenbank-Engine.

2. Deaktivieren der Binärprotokollierung für die Replikationsquelle

Im Folgenden finden Sie die Anweisungen zum Deaktivieren der Binärprotokollierung an der Replikationsquelle für Ihre Datenbank-Engine.

Verwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-Datenbank

Sie können Amazon Aurora mit Ihrer MySQL-DB-Instance verwenden, um die Möglichkeiten der Skalierung von Lesevorgängen von Amazon Aurora zu nutzen und den Lese-Workload für Ihre MySQL-DB-Instance zu erweitern. Erstellen Sie einen Amazon-Aurora MySQL-DB-Cluster und machen Sie ihn zum Read Replica Ihrer MySQL-DB-Instance, um Aurora für die Skalierung von Lesevorgängen Ihrer MySQL-DB-Instance zu verwenden. Dies gilt für eine RDS for MySQL-DB-Instance oder eine MySQL-Datenbank, die außerhalb von Amazon RDS ausgeführt wird.

Weitere Informationen zum Erstellen eines Amazon Aurora-DB-Clusters finden Sie unter Erstellen eines Amazon Aurora-DB Clusters.

Wenn Sie eine Replikation zwischen Ihrer MySQL-DB-Instance und Ihrem Amazon Aurora-DB-Cluster einrichten, folgen Sie sicherheitshalber bitte diesen Anweisungen:

  • Verwenden Sie die Amazon Aurora-DB-Cluster-Endpunkt-Adresse, wenn Sie Ihr Amazon Aurora MySQL-DB-Cluster referenzieren. Bei einem Failover verwendet die Aurora-Replica, die zur primären Instance for das Aurora MySQL-DB-Cluster hochgestuft wird, weiterhin die DB-Cluster-Endpunkt-Adresse.

  • Bewahren Sie die Binärprotokolle auf Ihrer Schreiber-Instance auf, bis Sie sichergestellt haben, dass sie auf das Aurora Replica angewandet wurden. Durch das Aufbewahren können Sie sicherstellen, dass Sie Ihre Schreiber-Instance im Fall eines Ausfalls wiederherstellen können.

Wichtig

Wenn Sie eine von Ihnen verwaltete Replikation verwenden, sind Sie für die Überwachung und Lösung jeglicher auftretender Probleme bei der Replikation verantwortlich. Weitere Informationen finden Sie unter Diagnose und Lösung bei Verzögerungen zwischen Read Replicas (Lesereplikaten).

Anmerkung

Die erforderlichen Berechtigungen zum Starten einer Replikation in einem Amazon-Aurora-MySQL-DB-Cluster sind beschränkt und für Ihren Amazon-RDS-Hauptbenutzer nicht verfügbar. Aus diesem Grund müssen Sie die Prozedurenmysql.rds_set_external_master (Aurora-MySQL-Version 2), mysql.rds_set_external_source (Aurora MySQL Version 3) und mysql.rds_start_replication verwenden, um eine Replikation zwischen Ihrem Aurora-MySQL-DB-Cluster und Ihrer MySQL-DB-Instance einzurichten.

Starten der Replikation zwischen einer externen Quell-Instance und einem MySQL-DB-Cluster

  1. Legen Sie die Quell-MySQL-DB-Instance als schreibgeschützt fest: 

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;

  2. Führen Sie den Befehl SHOW MASTER STATUS in der Quell-MySQL-DB-Instance aus, um den Speicherort des Binärprotokolls zu bestimmen. Sie erhalten eine Ausgabe, ähnlich der im folgenden Beispiel: 

    File                        Position
------------------------------------
 mysql-bin-changelog.000031      107
------------------------------------

  3. Kopieren Sie die Datenbank mithilfe von aus der externen MySQL-DB-Instance in das Amazon Aurora MySQL-DB-Cluster mysqldump. Bei sehr großen Datenbanken empfiehlt es sich, das Verfahren zu verwenden, das im Abschnitt zum Importieren von Daten in eine MySQL- oder MariaDB-DB-Instance mit reduzierter Ausfallzeit im Amazon Relational Database Service-Benutzerhandbuch beschrieben ist.

    Für LinuxmacOS, oderUnix:

    mysqldump \
    --databases <database_name> \
    --single-transaction \
    --compress \
    --order-by-primary \
    -u local_user \
    -p local_password | mysql \
        --host aurora_cluster_endpoint_address \
        --port 3306 \
        -u RDS_user_name \
        -p RDS_password

    Windows:

    mysqldump ^
    --databases <database_name> ^
    --single-transaction ^
    --compress ^
    --order-by-primary ^
    -u local_user ^
    -p local_password | mysql ^
        --host aurora_cluster_endpoint_address ^
        --port 3306 ^
        -u RDS_user_name ^
        -p RDS_password
    Anmerkung

    Stellen Sie sicher, dass kein Leezeichen zwischen der Option -p und dem eingegebenen Passwort vorhanden ist.

    Verwenden Sie die Optionen --host, --user (-u) --port und -p im Befehl mysql, um den Host-Namen, Benutzernamen, Port und das Passwort für die Verbindung mit Ihrem Aurora-DB-Cluster anzugeben. Der Host-Name ist der DNS-Name aus dem Amazon Aurora-DB-Cluster-Endpunkt, z. B, mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com. Sie finden den Endpunktwert in den Cluster-Details in der Amazon RDS-Managementkonsole.

  4. Legen Sie die Quell-MySQL-DB-Instance als wieder beschreibbar fest:

    mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;

    Weitere Informationen zum Erstellen von Backups zur Verwendung mit der Replikation finden Sie unter Backing up a source or replica by making it read only in der MySQL-Dokumentation.

  5. Fügen Sie in der Amazon RDS-Management Console die IP-Adresse des Servers, der die Quell-MySQL-Datenbank hostet, zu der VPC-Sicherheitsgruppe für das Amazon Aurora-DB-Cluster hinzu. Weitere Informationen zum Ändern einer VPC-Sicherheitsgruppe finden Sie unter Sicherheitsgruppen für Ihre VPC im Amazon Virtual Private Cloud-Benutzerhandbuch.

    Es könnte sein, dass Sie Ihr lokales Netzwerk so konfigurieren müssen, dass es Verbindungen von der IP-Adresse Ihres Amazon Aurora-DB-Clusters zulässt, damit Sie mit Ihrer Quell-MySQL-Datenbank kommunizieren können. Verwenden Sie den Befehl host, um die IP-Adresse des Amazon Aurora-DB-Clusters herauszufinden.

    host aurora_endpoint_address

    Der Hostname ist der DNS-Name aus dem Amazon Aurora-DB-Cluster-Endpunkt.

  6. Verbinden Sie sich mithilfe eines Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie einen MySQL-Benutzer, der für die Replikation verwendet werden soll. Dieses Konto wird ausschließlich für die Replikation verwendet und muss auf Ihre Domäne beschränkt sein, um die Sicherheit zu erhöhen. Im Folgenden wird ein Beispiel gezeigt.

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';

  7. Erteilen Sie Ihrem Replikationsbenutzer für die externe MySQL-Instance die Sonderrechte REPLICATION CLIENT und REPLICATION SLAVE. Erteilen Sie beispielsweise die Sonderrechte REPLICATION CLIENT und REPLICATION SLAVE in allen Datenbank für den 'repl_user'-Benutzer für Ihre Domäne, mit dem folgenden Befehl.

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
    IDENTIFIED BY 'password';

  8. Machen Sie einen manuellen Snapshot des Aurora MySQL-DB-Clusters, der das Read Replica sein soll, bevor Sie eine Replikation einrichten. Wenn Sie erneut eine Replikation mit dem DB-Cluster als Read Replica einrichten müssen, können Sie das Aurora MySQL-DB-Cluster aus diesem Snapshot wiederherstellen, anstatt die Daten aus Ihrer-MySQL-DB-Instance in ein neues Aurora MySQL-DB-Cluster importieren zu müssen.

  9. Legen Sie das Amazon Aurora-DB-Cluster als Replica fest. Verbinden Sie sich als Hauptbenutzer mit dem Amazon-Aurora-DB-Cluster und bestimmen Sie die MySQL-Quelldatenbank mithilfe der Prozeduren mysql.rds_set_external_master (Aurora-MySQL-Version 2) oder mysql.rds_set_external_source (Aurora MySQL Version 3) und mysql.rds_start_replication als Replikationsmaster.

    Verwenden Sie den Namen und die Position der Protokolldatei, die Sie in Schritt 2 festgelegt haben. Im Folgenden wird ein Beispiel gezeigt.

    For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

  10. Rufen Sie auf dem Amazon-Aurora-DB-Cluster die mysql.rds_start_replication-Prozedur auf, um die Replikation zu starten.

    CALL mysql.rds_start_replication;

Nachdem Sie die Replikation zwischen Ihrer Quell-MySQL-DB-Instance und Ihrem Amazon Aurora-DB-Cluster erneut eingerichtet haben, können Sie Aurora-Replicas zu Ihrem Amazon Aurora-DB-Cluster hinzufügen. Sie können sich anschließend mit dem Aurora Replicas verbinden, um die Lesevorgänge Ihrer Daten zu skalieren. Weitere Informationen über das Erstellen einer Aurora-Replica finden Sie unter Hinzufügen von Aurora-Replicas zu einem DB-Cluster.

Optimieren der binären Protokollreplikation

Im Folgenden erfahren Sie, wie Sie die Leistung der binären Protokollreplikation optimieren und damit zusammenhängende Probleme in Aurora MySQL beheben können.

Tipp

In dieser Erörterung wird davon ausgegangen, dass Sie mit dem Mechanismus der binären MySQL-Protokollreplikation und dessen Funktionsweise vertraut sind. Hintergrundinformationen finden Sie unter Replication Implementation (Implementierung der Replikation) in der MySQL-Dokumentation.

Multithread-Binärprotokollreplikation (Aurora MySQL Version 3)

Bei der Multithread-Replikation für binäre Protokolle liest ein SQL-Thread Ereignisse aus dem Relay-Log und stellt sie in die Warteschlange, damit SQL-Worker-Threads angewendet werden können. Die SQL-Worker-Threads werden von einem Koordinator-Thread verwaltet. Die binären Protokollereignisse werden nach Möglichkeit parallel angewendet.

Wenn eine Aurora MySQL-Instance für die Verwendung der binären Protokollreplikation konfiguriert ist, verwendet die Replikatinstanz standardmäßig die Single-Thread-Replikation für Aurora MySQL-Versionen unter 3.04. Um die Multithread-Replikation zu aktivieren, aktualisieren Sie den replica_parallel_workers-Parameter in Ihrer benutzerdefinierten Parametergruppe auf einen Wert größer als Null.

Für Aurora MySQL Version 3.04 und höher erfolgt die Replikation standardmäßig in mehreren Threads, wobei die Einstellung auf replica_parallel_workers gesetzt ist. 4 Sie können diesen Parameter in Ihrer benutzerdefinierten Parametergruppe ändern.

Die folgenden Konfigurationsoptionen helfen Ihnen bei der Optimierung der Multithread-Replikation. Informationen zur Verwendung finden Sie unter Replikations- und binäre Protokollierungsoptionen und -Variablen im MySQL-Verweishandbuch.

Die optimale Konfiguration hängt von mehreren Faktoren ab. Beispielsweise wird die Leistung für die Binärprotokollreplikation von Ihren Datenbank-Workload-Merkmalen und der DB-Instanzklasse beeinflusst, auf der das Replikat ausgeführt wird. Wir empfehlen Ihnen daher, alle Änderungen an diesen Konfigurationsparametern gründlich zu testen, bevor Sie neue Parametereinstellungen auf eine Produktionsinstanz anwenden:

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

In Aurora MySQL Version 3.06 und höher können Sie die Leistung für binäre Protokollreplikate verbessern, wenn Sie Transaktionen für große Tabellen mit mehr als einem sekundären Index replizieren. Diese Funktion führt einen Threadpool ein, um sekundäre Indexänderungen parallel auf ein Binlog-Replikat anzuwenden. Die Funktion wird durch den aurora_binlog_replication_sec_index_parallel_workers DB-Cluster-Parameter gesteuert, der die Gesamtzahl der parallel Threads steuert, die für die Anwendung der sekundären Indexänderungen verfügbar sind. Der Parameter ist standardmäßig auf 0 (deaktiviert) gesetzt. Für die Aktivierung dieser Funktion ist kein Instanzneustart erforderlich. Um diese Funktion zu aktivieren, beenden Sie die laufende Replikation, legen Sie die gewünschte Anzahl parallel Worker-Threads fest und starten Sie die Replikation dann erneut.

Sie können diesen Parameter auch als globale Variable verwenden, wobei n die Anzahl der parallel Worker-Threads ist:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Optimierung der Binlog-Replikation (Aurora MySQL 2.10 und höher)

In Aurora MySQL 2.10 und höher wendet Aurora automatisch eine Optimierung an, die als Binlog-I/O-Cache bekannt ist, auf die Binärlog-Replikation. Durch Zwischenspeichern der zuletzt festgeschriebenen Binlog-Ereignisse soll diese Optimierung die Leistung des Binlog-Dump-Threads verbessern und gleichzeitig die Auswirkungen auf Vordergrundtransaktionen auf der Binlog-Quell-Instance begrenzen.

Anmerkung

Dieser für diese Funktion verwendete Speicher ist unabhängig von der binlog_cache MySQL-Einstellung.

Diese Funktion gilt nicht für Aurora DB-Instances, die die db.t2- und db.t3-Instanceklassen verwenden.

Sie müssen keine Konfigurationsparameter anpassen, um diese Optimierung zu aktivieren. Insbesondere wenn Sie den Konfigurationsparameter aurora_binlog_replication_max_yield_seconds in früheren Aurora MySQL-Versionen auf einen Wert ungleich null eingestellt haben, setzen Sie ihn für Aurora MySQL 2.10 und höher auf null zurück.

Die Statusvariablen aurora_binlog_io_cache_reads und aurora_binlog_io_cache_read_requests sind in Aurora MySQL 2.10 und höher verfügbar. Diese Statusvariablen helfen Ihnen zu überwachen, wie oft die Daten aus dem Binlog-I/O-Cache gelesen werden.

  • aurora_binlog_io_cache_read_requests zeigt die Anzahl der Binlog-I/O-Leseanfragen aus dem Cache an.

  • aurora_binlog_io_cache_reads zeigt die Anzahl der Binlog-I/O-Lesevorgänge an, die Informationen aus dem Cache abrufen.

Die folgende SQL-Abfrage berechnet den Prozentsatz der Binlog-Leseanforderungen, die die zwischengespeicherten Informationen nutzen. In diesem Fall ist es umso besser, je näher das Verhältnis an 100 liegt. 

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

Die Binlog-I/O-Cache-Funktion enthält auch neue Metriken im Zusammenhang mit den Binlog-Dump-Threads. Dump-Threads sind die Threads, die erstellt werden, wenn neue Binlog-Replikate mit der Binlog-Quell-Instance verbunden sind.

Die Metriken des Dump-Threads werden alle 60 Sekunden mit dem Präfix in das Datenbankprotokoll gedruck [Dump thread metrics]. Die Metriken umfassen Informationen für jedes Binlog-Replikat wie Secondary_id, Secondary_uuid, den Namen der Binlog-Datei und die Position, die jedes Replikat liest. Zu den Metriken gehört auch Bytes_behind_primary, das den Abstand in Byte zwischen Replikationsquelle und Replikat darstellt. Diese Metrik misst die Verzögerung des Replikat-I/O-Threads. Diese Zahl unterscheidet sich von der Verzögerung des Replikat-SQL-Applier-Threads, der durch die seconds_behind_master Metrik auf dem Binlog-Replikat dargestellt wird. Sie können feststellen, ob Binlog-Replikate die Quelle aufholen oder zurückfallen, indem Sie überprüfen, ob die Entfernung abnimmt oder zunimmt.

Optimierung der Binlog-Replikation (Aurora-MySQL-Version 2 bis 2.09)

Um die binäre Protokollreplikation für Aurora MySQL zu optimieren, passen Sie die folgenden Optimierungsparameter auf Clusterebene an. Diese Parameter helfen Ihnen, das richtige Gleichgewicht zwischen Latenz für die Binärprotokoll-Quell-Instance und Replikationsverzögerung anzugeben.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

Anmerkung

Für MySQL 5.7-kompatible Cluster können Sie diese Parameter in Aurora-MySQL-Version 2 bis 2.09* verwenden. In Aurora MySQL 2.10.0 und höher werden diese Parameter durch die Binlog-I/O-Cache-Optimierung ersetzt und Sie müssen sie nicht verwenden.

Überblick über den großen Lese-Puffer und die Max-Yield-Optimierung

Es kann zu einer verringerten Leistung der binären Protokollreplikation kommen, wenn der binäre Protokoll-Dump-Thread auf das Aurora Cluster-Volume zugreift, während der Cluster eine hohe Anzahl von Transaktionen verarbeitet Sie können die Parameter aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds und aurora_binlog_read_buffer_size verwenden, um diese Art von Konflikt zu minimieren.

Angenommen, Sie haben eine Situation, in der aurora_binlog_replication_max_yield_seconds auf größer als 0 gesetzt ist und die aktuelle Binlog-Datei des Dump-Threads aktiv ist. In diesem Fall wartet der binäre Protokoll-Dump-Thread bis zu einer bestimmten Anzahl von Sekunden, bis die aktuelle Binärprotokolldatei durch Transaktionen gefüllt wird. Diese Wartezeit vermeidet Konflikte, die sich aus der Replikation jedes Binärprotokoll-Ereignisses ergeben können. Dies erhöht jedoch die Replica-Verzögerung für binäre Protokollreplikationen. Diese Replicas können um die gleiche Anzahl von Sekunden wie die aurora_binlog_replication_max_yield_seconds-Einstellung hinter die Quelle zurückfallen.

Die aktuelle Binärprotokolldatei ist die Binärprotokolldatei, die der Dump-Thread gerade liest, um die Replikation durchzuführen. Wir berücksichtigen, dass eine Binärprotokolldatei aktiv ist, wenn die Binärprotokolldatei aktualisiert oder geöffnet wird, um durch eingehende Transaktionen aktualisiert zu werden. Nach dem Aurora MySQL die aktive Binärprotokolldatei ausfüllt, erstellt MySQL eine neue Binärprotokolldatei und wechselt dieser Binärprotokolldatei. Die alte Binärprotokolldatei wird inaktiv. Es wird nicht mehr von eingehenden Transaktionen aktualisiert.

Anmerkung

Bevor Sie diese Parameter anpassen, messen Sie Ihre Transaktionslatenz und Ihren Durchsatz über die Zeit. Möglicherweise stellen Sie fest, dass die Leistung der binären Protokollreplikation stabil ist und eine geringe Latenz aufweist, selbst wenn gelegentliche Konflikte auftreten.

aurora_binlog_use_large_read_buffer

Wenn dieser Parameter auf 1 gesetzt ist, wird Aurora MySQL die binäre Protokollreplikation basierend auf den Einstellungen der Parameter aurora_binlog_read_buffer_size und aurora_binlog_replication_max_yield_seconds optimieren. Wenn aurora_binlog_use_large_read_buffer 0 ist, ignoriert Aurora MySQL die Werte der Parameter aurora_binlog_read_buffer_size und aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Binäre Protokoll-Dump-Threads mit größerem Lesepuffer minimieren die Anzahl der Lese-I/O-Vorgänge, indem sie weitere Ereignisse für jede I/O lesen. Der Parameter aurora_binlog_read_buffer_size legt die Größe des Lesepuffers fest. Der große Lesepuffer kann den Konflikt zwischen Binärprotokollen für Workloads reduzieren, die eine große Menge an Binärprotokoll-Daten erzeugen.

Anmerkung

Dieser Parameter hat nur Auswirkungen, wenn der Cluster auch die Einstellung ha aurora_binlog_use_large_read_buffer=1.

Eine Erhöhung der Größe des Lesepuffers hat keinen Einfluss auf die Leistung der binären Protokollreplikation. Binäre Protokoll-Dump-Threads warten nicht darauf, dass die Aktualisierung von Transaktionen den Lesepuffer füllt.

aurora_binlog_replication_max_yield_seconds

Wenn Ihr Workload eine geringe Transaktionslatenz erfordert und Sie eine gewisse Replikationsverzögerung tolerieren können, können Sie den Parameter aurora_binlog_replication_max_yield_seconds erhöhen. Dieser Parameter steuert die Eigenschaft „Maximum Yield“ der binären Protokollreplikation in Ihrem Cluster.

Anmerkung

Dieser Parameter hat nur Auswirkungen, wenn der Cluster auch die Einstellung ha aurora_binlog_use_large_read_buffer=1.

Aurora MySQL erkennt jede Änderung des aurora_binlog_replication_max_yield_seconds-Parameterwerts sofort. Sie müssen die DB-Instance nicht neu starten. Wenn Sie diese Einstellung aktivieren, beginnt der Dump-Thread jedoch erst dann zu arbeiten, wenn die aktuelle Binärprotokolldatei ihre maximale Größe von 128 MB erreicht und in eine neue Datei gedreht wird.

Zugehörige Parameter

Verwenden Sie die folgenden DB-Cluster-Parameter, um die Binärprotokoll-Optimierung zu aktivieren.

Parameter Standard Zulässige Werte Beschreibung
aurora_binlog_use_large_read_buffer 1 0, 1 Schalter zum Einschalten der Replikationsverbesserung. Wenn der Wert 1 ist, verwendet der binäre Protokoll-Dump-Thread aurora_binlog_read_buffer_size für die binäre Protokollreplikation, andernfalls wird die Standardpuffergröße (8 K) verwendet. In Aurora-MySQL-Version 3 nicht verwendet.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Liest die Puffergröße, die vom binären Protokoll-Dump-Thread verwendet wird, wenn der Parameter aurora_binlog_use_large_read_buffer auf 1 gesetzt ist. In Aurora-MySQL-Version 3 nicht verwendet.
aurora_binlog_replication_max_yield_seconds 0 0 -36000

Der maximal zulässige Wert für Aurora-MySQL-Version 2.07* ist 45. Unter 2.09 und späteren Versionen können Sie einen höheren Wert einstellen.

Für Version 2 funktioniert dieser Parameter nur, wenn der Parameter aurora_binlog_use_large_read_buffer auf 1 gesetzt ist.

Aktivieren des Max-Yield-Mechanismus für die binäre Protokollreplikation

Sie können die Max-Yield-Optimierung der binären Protokollreplikation wie folgt aktivieren. Dadurch wird die Latenz für Transaktionen auf der Binärprotokoll-Quell-Instance minimiert. Es kann jedoch zu einer höheren Verzögerung bei der Replikation kommen.

Aktivieren der Max-Yield-Binlog-Optimierung für einen Aurora-MySQL-Cluster

  1. Erstellen oder bearbeiten Sie eine DB-Clusterparametergruppe unter Verwendung der folgenden Parametereinstellungen:

    • aurora_binlog_use_large_read_buffer: schaltet sich mit einem Wert von ON oder 1 ein.

    • aurora_binlog_replication_max_yield_seconds: Geben Sie einen Wert größer als 0 ein.

  2. Ordnen Sie die DB-Cluster-Parametergruppe dem Aurora MySQL-Cluster zu, der als Binärprotokoll-Quelle arbeitet. Befolgen Sie hierzu die Verfahren unter Arbeiten mit Parametergruppen.

  3. Bestätigen Sie, dass die Parameteränderung wirksam wird. Führen Sie dazu die folgende Abfrage für die Binärprotokoll-Quell-Instance aus. 

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    Die Ausgabe sollte in etwa wie folgt aussehen. 

    +---------------------------------------+-----------------------------------------------+
| @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
+---------------------------------------+-----------------------------------------------+
|                                     1 |                                            45 |
+---------------------------------------+-----------------------------------------------+

Deaktivieren der Max-Yield-Optimierung der binären Protokollreplikation

Sie können die Max-Yield-Optimierung der binären Protokollreplikation wie folgt deaktivieren. Dadurch wird die Verzögerung bei der Replikation minimiert. Es kann jedoch zu einer höheren Latenz für Transaktionen auf der Binärprotokoll-Quell-Instance kommen.

Deaktivieren der Max-Yield-Optimierung für einen Aurora MySQL-Cluster

  1. Stellen Sie sicher, das bei der DB-Clusterparametergruppe, die dem Aurora MySQL-Cluster zugeordnet ist, aurora_binlog_replication_max_yield_seconds auf 0 eingestellt ist. Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter Arbeiten mit Parametergruppen.

  2. Bestätigen Sie, dass die Parameteränderung wirksam wird. Führen Sie dazu die folgende Abfrage für die Binärprotokoll-Quell-Instance aus. 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    Die Ausgabe sollte in etwa wie folgt aussehen. 

    +-----------------------------------------------+
| @@aurora_binlog_replication_max_yield_seconds |
+-----------------------------------------------+
|                                             0 |
+-----------------------------------------------+

Ausschalten des großen Lesepuffers

Sie können die gesamte Funktion für große Lesepuffer wie folgt deaktivieren.

So schalten Sie den großen Lesepuffer für das binäre Protokoll für einen Aurora MySQL Cluster aus

  1. Setzen Sie aurora_binlog_use_large_read_buffer auf OFF oder 0 zurück:

    Stellen Sie sicher, das bei der DB-Clusterparametergruppe, die dem Aurora MySQL-Cluster zugeordnet ist, aurora_binlog_use_large_read_buffer auf 0 eingestellt ist. Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter Arbeiten mit Parametergruppen.

  2. On the binlog source instance, run the following query. 

    SELECT @@ aurora_binlog_use_large_read_buffer;

    Die Ausgabe sollte in etwa wie folgt aussehen. 

    +---------------------------------------+
| @@aurora_binlog_use_large_read_buffer |
+---------------------------------------+
|                                     0 |
+---------------------------------------+

Einrichten eines erweiterten Binärprotokolls

Das erweiterte Binärprotokoll reduziert den durch die Aktivierung des Binärprotokolls verursachten Rechenleistungs-Overhead, der in bestimmten Fällen bis zu 50 % betragen kann. Mit einem erweiterten Binärprotokoll kann dieser Overhead auf etwa 13 % reduziert werden. Damit der Overhead reduziert wird, schreibt das erweiterte Binärprotokoll die Binär- und Transaktionsprotokolle parallel in den Speicher, wodurch die zum Zeitpunkt des Transaktions-Commits geschriebenen Daten minimiert werden.

Die Verwendung des erweiterten Binärprotokolls verbessert außerdem die Datenbankwiederherstellungszeit nach Neustarts und Failovers um bis zu 99 % im Vergleich zum Community-MySQL-Binärprotokoll.  Das erweiterte Binärprotokoll ist mit bestehenden binlogbasierten Workloads kompatibel und Sie interagieren damit genauso wie mit dem Community-MySQL-Binärprotokoll.

Das erweiterte Binlog ist auf Aurora MySQL Version 3.03.1 und höher verfügbar.

Konfiguration erweiterter Binärprotokollparameter

Sie können zwischen Community-MySQL-Binärprotokoll und erweitertem Binärprotokoll wechseln, indem Sie die Parameter für das erweiterte Binärprotokoll aktivieren/deaktivieren. Die bestehenden Binärprotokollbenutzer können die Binärprotokolldateien weiterhin lesen und verarbeiten, ohne dass es zu Lücken in der Binärprotokolldateifolge kommt.

So aktivieren Sie das erweiterte Binärprotokoll
Parameter Standard Beschreibung
binlog_format – Legen Sie den Parameter binlog_format auf das binäre Protokollierungsformat Ihrer Wahl fest, um das erweiterte Binärprotokoll zu aktivieren. Stellen Sie sicher, dass der binlog_format parameter nicht auf AUS eingestellt ist. Weitere Informationen finden Sie unter Konfiguration der binären Protokollierung mit Aurora MySQL.
aurora_enhanced_binlog 0 Legen Sie den Wert dieses Parameters in der Parametergruppe des DB-Clusters, die mit dem Aurora-MySQL-Cluster verknüpft ist, auf 1 fest. Wenn Sie den Wert dieses Parameters ändern, müssen Sie die Writer-Instance neu starten, wenn für den Wert DBClusterParameterGroupStatus pending-reboot angezeigt wird.
binlog_backup 1 Deaktivieren Sie diesen Parameter, um das erweiterte Binärprotokoll zu aktivieren. Legen Sie dazu den Wert dieses Parameters auf 0 fest.
binlog_replication_globaldb 1 Deaktivieren Sie diesen Parameter, um das erweiterte Binärprotokoll zu aktivieren. Legen Sie dazu den Wert dieses Parameters auf 0 fest.
Wichtig

Sie können die Parameter binlog_backup und binlog_replication_globaldb nur deaktivieren, wenn Sie das erweiterte Binärprotokoll verwenden.

So deaktivieren Sie das erweiterte Binärprotokoll
Parameter Beschreibung
aurora_enhanced_binlog Legen Sie den Wert dieses Parameters in der Parametergruppe des DB-Clusters, die mit dem Aurora-MySQL-Cluster verknüpft ist, auf 0 fest. Sobald Sie den Wert dieses Parameters ändern, müssen Sie die Writer-Instance neu starten, wenn für den Wert DBClusterParameterGroupStatus pending-reboot angezeigt wird.
binlog_backup Aktivieren Sie diesen Parameter, wenn Sie das erweiterte Binärprotokoll deaktivieren. Legen Sie dazu den Wert dieses Parameters auf 1 fest.
binlog_replication_globaldb Aktivieren Sie diesen Parameter, wenn Sie das erweiterte Binärprotokoll deaktivieren. Legen Sie dazu den Wert dieses Parameters auf 1 fest.

Um zu überprüfen, ob das erweiterte Binärprotokoll aktiviert ist, verwenden Sie den folgenden Befehl im MySQL-Client:

mysql>show status like 'aurora_enhanced_binlog';
              
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)

Wenn das erweiterte Binärprotokoll aktiviert ist, wird in der Ausgabe ACTIVE für aurora_enhanced_binlog angezeigt.

Sonstige zugehörige Parameter

Wenn Sie das erweiterte Binärprotokoll aktivieren, sind folgende Parameter betroffen:

  • Der Parameter max_binlog_size ist sichtbar, kann aber nicht geändert werden. Sein Standardwert 134217728 wird automatisch in 268435456 geändert, wenn das erweiterte Binärprotokoll aktiviert ist.

  • Im Gegensatz zum Community-MySQL-Binärprotokoll fungiert binlog_checksum nicht als dynamischer Parameter, wenn das erweiterte Binärprotokoll aktiviert ist. Damit die Änderung an diesem Parameter wirksam wird, müssen Sie den DB-Cluster manuell neu starten, auch wenn für ApplyMethod immediate festgelegt ist.

  • Der Wert, den Sie für den Parameter binlog_order_commits festlegen, hat keinen Einfluss auf die Reihenfolge der Commits, wenn das erweiterte Binärprotokoll aktiviert ist. Die Commits werden immer ohne weitere Auswirkungen auf die Leistung angeordnet.

Unterschiede zwischen erweitertem Binärprotokoll und Community-MySQL-Binärprotokoll

Das erweiterte Binlog interagiert anders mit Klonen, Backups und der globalen Aurora-Datenbank als das Community-MySQL-Binlog. Bevor Sie das erweiterte Binärprotokoll verwenden, sollten Sie sich mit den folgenden Unterschieden vertraut machen.

  • Verbesserte Binlogdateien aus dem Quell-DB-Cluster sind auf einem geklonten DB-Cluster nicht verfügbar.

  • Verbesserte Binlogdateien sind nicht in Aurora-Backups enthalten. Daher sind erweiterte Binärprotokolldateien aus dem Quell-DB-Cluster nach der Wiederherstellung eines DB-Clusters trotz einer für ihn festgelegten Aufbewahrungsfrist nicht verfügbar.

  • Bei Verwendung mit einer globalen Aurora-Datenbank werden die erweiterten Binärprotokolldateien des primären DB-Clusters nicht auf den DB-Cluster in den sekundären Regionen repliziert.

Beispiele

Die folgenden Beispiele veranschaulichen die Unterschiede zwischen dem erweiterten Binärprotokoll und dem Community-MySQL-Binärprotokoll.

Auf einem wiederhergestellten oder geklonten DB-Cluster

Wenn das erweiterte Binärprotokoll aktiviert ist, sind die historischen Binärprotokolldateien im wiederhergestellten oder geklonten DB-Cluster nicht verfügbar. Wenn Binlog nach einem Wiederherstellungs- oder Klonvorgang aktiviert ist, beginnt der neue DB-Cluster mit dem Schreiben seiner eigenen Sequenz von Binlogdateien, beginnend bei 1 (mysql-bin-changelog.000001).

Um das erweiterte Binärprotokoll nach einem Wiederherstellungs- oder Klonvorgang zu aktivieren, legen Sie die erforderlichen DB-Cluster-Parameter auf dem wiederhergestellten oder geklonten DB-Cluster fest. Weitere Informationen finden Sie unter Konfiguration erweiterter Binärprotokollparameter.

Beispiel Ausführung des Klon- oder Wiederherstellungsvorgangs, wenn das erweiterte Binärprotokoll aktiviert ist

Quell-DB-Cluster:

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

In einem wiederhergestellten oder geklonten DB-Cluster werden Binärprotokolldateien nicht gesichert, wenn das erweiterte Binärprotokoll aktiviert ist. Um Unterbrechungen in den Binärprotokolldaten zu vermeiden, sind die Binärprotokolldateien, die vor dem Aktivieren des erweiterten Binärprotokolls geschrieben wurden, ebenfalls nicht verfügbar. 

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> New sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
Beispiel Der Klonen- oder Wiederherstellungsvorgang wird ausgeführt, wenn das erweiterte Binlog ausgeschaltet ist

Quell-DB-Cluster:

mysql>show binary logs;
                                                
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

In einem wiederhergestellten oder geklonten DB-Cluster sind Binärprotokolldateien verfügbar, die nach dem Deaktivieren des erweiterten Binärprotokoll geschrieben wurden.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)

In einer Amazon Aurora Global Database

In einer Amazon Aurora Global Database werden die Binärprotokolldaten des primären DB-Clusters nicht auf den sekundären DB-Cluster repliziert. Nach einem regionsübergreifenden Failover-Prozess sind die Binärprotokolldaten im neu hochgestuften primären DB-Cluster nicht verfügbar. Wenn Binlog aktiviert ist, startet der neu hochgestufte DB-Cluster seine eigene Sequenz von Binlogdateien, beginnend bei 1 (mysql-bin-changelog.000001).

Um das erweiterte Binärprotokoll nach einem Failover zu aktivieren, müssen Sie die erforderlichen DB-Cluster-Parameter auf dem sekundären DB-Cluster festlegen. Weitere Informationen finden Sie unter Konfiguration erweiterter Binärprotokollparameter.

Beispiel Ausführen eines globalen Datenbank-Failovers, wenn das erweiterte Binärprotokoll aktiviert ist

Alter primärer DB-Cluster (vor dem Failover):

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Neuer primärer DB-Cluster (nach dem Failover):

Binärprotokolldateien werden nicht in sekundäre Regionen repliziert, wenn das erweiterte Binärprotokoll aktiviert ist. Um Unterbrechungen in den Binärprotokolldaten zu vermeiden, sind die Binärprotokolldateien, die vor dem Aktivieren des erweiterten Binärprotokolls geschrieben wurden, nicht verfügbar.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
Beispiel Ausführen eines globalen Datenbank-Failovers, wenn das erweiterte Binärprotokoll deaktiviert ist

Quell-DB-Cluster:

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Wiederhergestellter oder geklonter DB-Cluster:

Binärprotokolldateien, die nach dem Deaktivieren des erweiterten Binärprotokolls geschrieben wurden, werden repliziert und sind im neu hochgestuften DB-Cluster verfügbar.

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)

CloudWatch Amazon-Metriken für erweitertes Binlog

Die folgenden CloudWatch Amazon-Metriken werden nur veröffentlicht, wenn das erweiterte Binlog aktiviert ist.

CloudWatch Metrik Beschreibung Einheiten
ChangeLogBytesUsed Die Menge des vom Speicherplatzes, der vom erweiterten Binärprotokoll belegt wird. Bytes
ChangeLogReadIOPs Die Anzahl von Lese-I/O-Operationen, die im erweiterten Binärprotokoll in einem fünfminütigen Intervalls durchgeführt wurden. Anzahl pro 5 Minuten
ChangeLogWriteIOPs Die Anzahl von Schreib-I/O-Operationen, die im erweiterten Binärprotokoll in einem fünfminütigen Intervalls durchgeführt wurden. Anzahl pro 5 Minuten

Beschränkungen für das erweiterte Binärprotokoll

Die folgenden Einschränkungen gelten für DB-Cluster von Amazon Aurora, wenn das erweiterte Binärprotokoll aktiviert ist.

  • Das erweiterte Binlog wird nur auf Aurora MySQL Version 3.03.1 und höher unterstützt.

  • Die auf dem primären DB-Cluster geschriebenen erweiterten Binärprotokolldateien werden nicht in die geklonten oder wiederhergestellten DB-Cluster kopiert.

  • Bei Verwendung mit Amazon Aurora Global Database werden die erweiterten Binärprotokolldateien des primären DB-Clusters nicht auf sekundäre DB-Cluster repliziert. Daher sind die historischen Binärprotokolldaten nach dem Failover-Prozess im neuen primären DB-Cluster nicht verfügbar.

  • Die folgenden Binärprotokoll-Konfigurationsparameter werden ignoriert:

    • binlog_group_commit_sync_delay

    • binlog_group_commit_sync_no_delay_count

    • binlog_max_flush_queue_time

  • Sie können eine beschädigte Tabelle in einer Datenbank nicht löschen oder umbenennen. Um diese Tabellen zu löschen, können Sie Kontakt aufnehmen. AWS Support

  • Der Binärprotokoll-I/O-Cache ist deaktiviert, wenn das erweiterte Binärprotokoll aktiviert ist. Weitere Informationen finden Sie unter Optimieren der binären Protokollreplikation .

    Anmerkung

    Das erweiterte Binärprotokoll bietet ähnliche Verbesserungen der Leseleistung wie der Binärprotokoll-I/O-Cache und deutliche Verbesserungen der Schreibleistung.

  • Die Rückverfolgungsfunktion wird nicht unterstützt. Das erweiterte Binärprotokoll kann in einem DB-Cluster unter den folgenden Bedingungen nicht aktiviert werden:

    • Für den DB-Cluster ist derzeit die Rückverfolgungsfunktion aktiviert.

    • DB-Cluster, in dem die Backtrack-Funktion zuvor aktiviert war, jetzt aber deaktiviert ist.

    • Der DB-Cluster wurde aus einem Quell-DB-Cluster oder einem Snapshot mit aktivierter Rückverfolgungsfunktion wiederhergestellt.