Anwendungsfälle für verzögerte Replikation Konfigurieren Sie die externe Replikation mit einer Verzögerung Ändern Sie die verzögerte Replikation für ein vorhandenes Read Replica Legen Sie einen Speicherort fest, an dem die Replikation auf ein Read Replica gestoppt werden soll Ein Read Replica hochstufen Verwandte Themen

Konfigurieren Sie die verzögerte Replikation mit Amazon Aurora MySQL

Sie können die verzögerte Replikation als Strategie für die Notfallwiederherstellung mit Aurora MySQL verwenden. Für die verzögerte Replikation geben Sie die Mindestanzahl von Sekunden an, um welche die Replikation von der Quelle in das Lesereplikat verzögert werden soll. Wenn es zu einem Notfall kommt, weil beispielsweise eine Tabelle versehentlich gelöscht wurde, können Sie das Problem mit den folgenden Schritten schnell beheben:

Beenden Sie die Replikation auf das Read Replica, bevor die Quelle die Änderung sendet, die das Desaster verursacht hat. Verwenden Sie die gespeicherte Prozedur mysql.rds_stop_replication, um die Replikation zu stoppen.
Starten Sie die Replikation und geben Sie an, dass die Replikation automatisch an einer bestimmten Position in der Protokolldatei stoppen soll. Mit der gespeicherten Prozedur mysql.rds_start_replication_until(Aurora MySQL Version 3) geben Sie eine Position unmittelbar vor Eintreten des Notfalls an.
Erhöhen Sie das Read Replica zum neuen Quell-DB-Cluster, indem Sie die Anweisungen unter befolgen. Hochstufen eines Lesereplikats zu einem DB-Cluster für Aurora MySQL

Anmerkung

Aurora MySQL unterstützt verzögerte Replikation für Version 8.4.8 und höher.

Verwenden Sie gespeicherte Prozeduren, um die verzögerte Replikation zu konfigurieren. Sie können die verzögerte Replikation nicht mit der AWS-Managementkonsole AWS CLI, der oder der Amazon RDS-API konfigurieren.
Sie können die Replikation auf der Grundlage globaler Transaktionsidentifikatoren (GTIDs) in einer Konfiguration mit verzögerter Replikation auf Aurora MySQL Version 8.4.8 und höher verwenden.
Wenn Sie die GTID-based Replikation verwenden, verwenden Sie die mysql.rds_start_replication_until_gtid (Aurora MySQL Version 3) gespeicherte Prozedur anstelle der gespeicherten Prozedur. mysql.rds_start_replication_until(Aurora MySQL Version 3)
Aurora MySQL unterstützt die Replikation aus mehreren Quellen mit bis zu 15 Kanälen. Verwenden Sie die _for_channel Verfahrensvarianten, um die verzögerte Replikation auf bestimmten Kanälen zu konfigurieren.

Themen

Anwendungsfälle für verzögerte Replikation
Konfigurieren Sie die externe Replikation mit einer Verzögerung
Ändern Sie die verzögerte Replikation für ein vorhandenes Read Replica
Legen Sie einen Speicherort fest, an dem die Replikation auf ein Read Replica gestoppt werden soll
Ein Read Replica hochstufen
Verwandte Themen

Anwendungsfälle für verzögerte Replikation

Die verzögerte Replikation auf Aurora MySQL gilt für die auf Binärprotokollen basierende Replikation. Dazu gehört die Replikation von einem Aurora MySQL Writer DB-Cluster auf ein Binlog-Replikat, von einer externen MySQL-Quelle in einen Aurora MySQL-DB-Cluster oder über Replikationskanäle mit mehreren Quellen. Dies gilt nicht für Aurora Replicas innerhalb eines einzelnen DB-Clusters, da diese aus dem gemeinsam genutzten Cluster-Speicher und nicht aus dem Binärlog lesen. Zu den häufigsten Anwendungsfällen gehören die folgenden:

Notfallwiederherstellung nach einem Bedienfehler — Pflegen Sie ein Binlog-Replikat, das der Quelle um ein festgelegtes Intervall hinterherhinkt. Wenn unbeabsichtigt eine destruktive Anweisung ausgeführt wird (z. B. weil eine Tabelle gelöscht wird), beenden Sie die Replikation auf dem verzögerten Replikat, bevor die Quelle die Änderung anwendet. Gehen Sie dann mit oder bis kurz vor dem Ereignis vor. mysql.rds_start_replication_until(Aurora MySQL Version 3) mysql.rds_start_replication_until_gtid (Aurora MySQL Version 3) Bewerben Sie abschließend das Replikat. Dieser Ansatz bietet einen schnelleren Recovery-Pfad als eine Point-in-Time-Wiederherstellung, bei der die Wiederherstellung nach einem Absturz und die Wiedergabe des Binärprotokolls erforderlich sind.
Schutz vor logischer Datenbeschädigung — Ein verzögertes Replikat schützt auch vor einer fehlerhaften Anwendungsbereitstellung oder Migration, durch die Daten allmählich beschädigt werden. Da das Replikat für die Dauer der Verzögerung den Status vor der Beschädigung beibehält, können Sie es wiederherstellen, bevor die fehlerhaften Transaktionen ausgeführt werden.
Hauptversion und blue/green Upgrades — Bewahren Sie während eines Upgrades oder einer blue/green Bereitstellung ein verzögertes Binlog-Replikat als Sicherheitsnetz auf, sodass Sie in einen zweifelsfrei funktionierenden Zustand zurückkehren können, falls das Upgrade zu Problemen führt.
Change Data Capture (CDC) aus einer externen Quelle — Wenn Sie Änderungen aus einer externen MySQL-Quelle in einen Aurora MySQL-DB-Cluster aufnehmen, erhalten Sie durch eine absichtliche Verzögerung einen kontrollierten Puffer, bevor die Änderungen im Downstream angewendet werden.
Historische Überprüfung ohne Wiederherstellung — Fragen Sie das verzögerte Replikat ab, um zu sehen, wie Ihre Daten zu einem früheren Zeitpunkt aussahen. Dies ist nützlich, um Fehler zu debuggen, zu überprüfen oder zu untersuchen, was sich geändert hat, ohne einen Klon bereitzustellen oder eine Point-in-Time-Wiederherstellung durchzuführen.
Testen des Anwendungsverhaltens unter Replikationsverzögerungen — Verwenden Sie eine künstlich überhöhte Verzögerung, um zu überprüfen, wie sich Ihre Anwendung verhält, wenn ein Replikat verzögert ist, und um Regressionstests für verzögerungsempfindliche Bedingungen durchzuführen, ohne eine hohe Last erzeugen zu müssen, um die Verzögerung zu reproduzieren.

Konfigurieren Sie die externe Replikation mit einer Verzögerung

Verwenden Sie die mysql.rds_set_external_source_with_delay (Aurora MySQL Version 8.4.8 und höher) gespeicherte Prozedur, um eine externe Quelle mit verzögerter Replikation zu konfigurieren. Weitere Hinweise zu allen gespeicherten Replikationsprozeduren finden Sie unterKonfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog).

Beispiel (Standardkanal):


CALL mysql.rds_set_external_source_with_delay(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600);

Beispiel (bestimmter Kanal):


CALL mysql.rds_set_external_source_with_delay_for_channel(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600,
  'channel_1');

Parameter:

host_name: Der Hostname oder die IP-Adresse der externen Quelle.
host_port: Die Portnummer der externen Quelle.
replication_user_name: Der Replikationsbenutzer auf der externen Quelle.
replication_user_password: Das Passwort für den Replikationsbenutzer.
mysql_binary_log_file_name: Der Name der binären Protokolldatei auf der externen Quelle.
mysql_binary_log_file_location: Die Position in der Binärprotokolldatei, an der mit der Replikation begonnen werden soll.
ssl_encryption: Stellen Sie diesen Parameter auf ein1, um die SSL-Verschlüsselung für die Replikationsverbindung zu aktivieren oder 0 um die SSL-Verschlüsselung zu deaktivieren.
delay: Die minimale Verzögerung in Sekunden (0—259.200).
channel: (Nur für die Variante for_channel) Der Kanalname für die Replikation mit mehreren Quellen.

Einschränkungen:

Aurora MySQL unterstützt maximal 15 Replikationskanäle.
Jeder Kanal muss von einer anderen Quelle repliziert werden (Host:Port-Kombination).
Die Verzögerung muss zwischen 0 und 259.200 Sekunden (72 Stunden) liegen.
Beenden Sie die Replikation, bevor Sie die Kanalkonfiguration ändern.

Ändern Sie die verzögerte Replikation für ein vorhandenes Read Replica

Führen Sie die gespeicherte Prozedur mysql.rds_set_source_delay (Aurora MySQL Version 8.4.8 und höher) aus, um die verzögerte Replikation eines vorhandenen Lesereplikats zu ändern. Weitere Hinweise zu allen gespeicherten Replikationsprozeduren finden Sie unterKonfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog).

So ändern Sie die verzögerte Replikation für ein vorhandenes Read Replica:

Stellen Sie mithilfe eines MySQL-Clients als Admin-Benutzer eine Verbindung zur Read Replica her.
Verwenden Sie die gespeicherte Prozedur mysql.rds_stop_replication, um die Replikation zu stoppen.
Führen Sie die gespeicherte Prozedur mysql.rds_set_source_delay (Aurora MySQL Version 8.4.8 und höher) aus.
Verwenden Sie die gespeicherte Prozedur mysql.rds_start_replication, um die Replikation zu starten.

Beispiel (Standardkanal):


CALL mysql.rds_set_source_delay(3600);

Beispiel (bestimmter Kanal):


CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');

Dies gibt an, dass die Replikation auf das Read Replica um mindestens eine Stunde (3.600 Sekunden) verzögert wird. Der Verzögerungswert muss zwischen 0 und 259.200 Sekunden (72 Stunden) liegen.

Anmerkung

Beenden Sie die Replikation, bevor Sie die Verzögerung festlegen. Wenn die Replikation läuft, erhalten Sie eine Fehlermeldung, in der Sie aufgefordert werden, zuerst mysql.rds_stop_replication (oder mysql.rds_stop_replication_for_channel für einen bestimmten Kanal) anzurufen.

Legen Sie einen Speicherort fest, an dem die Replikation auf ein Read Replica gestoppt werden soll

Nachdem Sie die Replikation für ein Lesereplikat gestoppt haben, können Sie die Replikation mit der gespeicherten Prozedur mysql.rds_start_replication_until(Aurora MySQL Version 3) starten und dann an einer angegebenen Position in der Binärprotokolldatei stoppen lassen.

Um die Replikation zu starten und an einem bestimmten Ort anzuhalten:

Stellen Sie mithilfe eines MySQL-Clients als Admin-Benutzer eine Verbindung zur Read Replica her.
Führen Sie die gespeicherte Prozedur mysql.rds_start_replication_until(Aurora MySQL Version 3) aus.

Beispiel:


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

Dadurch wird die Replikation initiiert und Änderungen repliziert, bis die Position 120 in der mysql-bin-changelog.000777 binären Protokolldatei erreicht ist. Gehen Sie in einem Disaster Recovery-Szenario davon aus, dass sich Standort 120 unmittelbar vor der Katastrophe befindet.

Die Replikation wird automatisch beendet, wenn Aurora MySQL den Stopppunkt erreicht. Aurora MySQL generiert das folgende Ereignis:Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Wenn Sie die GTID-based Replikation verwenden, verwenden Sie stattdessen die mysql.rds_start_replication_until_gtid (Aurora MySQL Version 3) gespeicherte Prozedur.

Ein Read Replica hochstufen

Nach dem Beenden der Replikation können Sie in einem Disaster Recovery-Szenario ein Read Replica zum neuen Quell-DB-Cluster heraufstufen. Weitere Informationen zum Hochstufen eines Lesereplikats finden Sie unter Hochstufen eines Lesereplikats zu einem DB-Cluster für Aurora MySQL.