Behebung von Replikationsfehlern aufgrund fehlender Datensätze

Wenn Sie Amazon RDS for MySQL oder MariaDB mit binärer Protokollreplikation verwenden, kann es zu Replikationsfehlern kommen, wenn der Prozess aufgrund fehlender Datensätze auf Read Replicas angehalten wird. In diesem Abschnitt wird erklärt, wie Sie diese Probleme diagnostizieren und lösen können.

Häufige Ursachen

Eine Dateninkonsistenz zwischen der Quelle und dem Replikat kann durch eines der folgenden Szenarien verursacht werden:

• Manuelle Datenänderung auf dem Replikat

• Transaktionen, die mit sql_replica_skip_counter (sql_slave_skip_countervor MySQL 8.0.26) übersprungen wurden

• Fehlende Zeilen im Replikat bei der ersten Datensynchronisierung mithilfe von Migrationstools

Identifizieren des Problems

Ein häufiger Indikator für dieses Error 1032 Problem ist die NachrichtCan't find record. Die folgende Fehlermeldung wird im Fehlerprotokoll des Replikats angezeigt:

2025-11-04T21:24:11.038899Z 566 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': 
Worker 1 failed executing transaction 'ANONYMOUS' at source log 
mysql-bin-changelog.031523, end_log_pos 899; Could not execute Update_rows event on 
table test_replication.users; Can't find record in 'users', Error_code: 1032; handler 
error HA_ERR_KEY_NOT_FOUND; the event's source log mysql-bin-changelog.031523, 
end_log_pos 899, Error_code: MY-001032

Anmerkung

Das Format des Fehlerprotokolls variiert zwischen MySQL- und MariaDB-Engines. Informationen zum Abrufen der Protokolle finden Sie unter. Anzeigen und Auflisten von Datenbank-Protokolldateien

Das Problem diagnostizieren

Um den Replikationsfehler zu diagnostizieren:

• Überprüfen Sie die Replikatfehlerprotokolle, um festzustellen, wo die Replikation gestoppt wurde. Sie können es MY-010584 als Suchbegriff verwenden.

• Führen Sie SHOW REPLICA STATUS\G (SHOW SLAVE STATUS\Gvor MySQL 8.0.22) auf dem Replikat aus und überprüfen Sie die Spalte: Last_Error

  Last_Error: Coordinator stopped because there were error(s) in the worker(s). 
  The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' 
  at source log mysql-bin-changelog.031523, end_log_pos 899. See error log and/or 
  performance_schema.replication_applier_status_by_worker table for more details 
  about this failure or others, if any.

• Überprüfen Sie den Namen der Binärprotokolldatei und die Position, an der der Replikationsprozess auf der Replikatinstanz gestoppt wurde. Sie finden diese Informationen im Fehlerprotokoll der Replikatinstanz.

Analysieren von Binärprotokollen

Um einen Replikationsfehler bei einer bestimmten Transaktion zu untersuchen, können Sie das mysqlbinlogHilfsprogramm verwenden, um die binäre Protokolldatei zu untersuchen. Wenn die Replikation beispielsweise an einer end_log_pos Position 899 in der Binärprotokolldatei fehlgeschlagen istmysql-bin-changelog.031523, können Sie diesen speziellen Speicherort analysieren, um die Ursache des Fehlers zu ermitteln.

Anmerkung

Der end_log_pos Wert gibt die Endposition des fehlgeschlagenen Ereignisses an. Suchen Sie in der dekodierten binären Protokollausgabe nach dem Ereignis, das diesem Wert end_log_pos entspricht.

Verwenden Sie das mysqlbinlog Hilfsprogramm, um das entsprechende Binärprotokoll herunterzuladen und zu untersuchen. Verwenden Sie den Endpunkt für die primäre Instanz.

$ mysqlbinlog --read-from-remote-server \
--host=<rds-endpoint> \
--port=3306 \
--user=<username> \
--password=<password> \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name

Anmerkung

Das mysqlbinlog Hilfsprogramm ist ein systemeigenes MySQL-Tool, mit dem Sie binäre Protokollinhalte lesen und interpretieren können. Weitere Informationen zum Zugriff auf Binärprotokolle auf Amazon RDS finden Sie unterZugriff auf MySQL-Binärprotokolle.

Das Binärprotokoll der Writer-Instance zeigt, dass die Writer-Instance versucht hat, einen Datensatz id=1 in der test_replication.users Tabelle zu aktualisieren:

#251104 21:13:13 server id 680788197  end_log_pos 899 CRC32 0x89b1e255     Update_rows: table id 101 flags: STMT_END_F
### UPDATE `test_replication`.`users`
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='[e-mail]' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='[e-mail]' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
# at 899

Aus den Fehlerprotokollen des Replikats geht hervor, dass das Replikat die UPDATE Anweisung nicht ausführen konnte, da der Zieldatensatz nicht existiert:

Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND

Um zu überprüfen, ob die Zeile fehlt, überprüfen Sie, ob die bestimmte Zeile im Replikat vorhanden ist:

SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)

Diese Ausgabe bestätigt, dass der UPDATE Vorgang von der Quell-DB-Instance aus nicht repliziert werden konnte, weil die Zielzeile im Replikat nicht vorhanden ist.

Vermeidung von Replikationsfehlern

Wir empfehlen die folgenden bewährten Methoden, um Replikationsinkonsistenzen zu vermeiden:

• Verwenden Sie die Replikation GTID-based . Weitere Informationen finden Sie unter GTID-based Replikation verwenden.

• Verwenden Sie binlog_format wie ROW auf der primären Instanz. Mit binlog_format as besteht bei der Replikation die MöglichkeitMIXED, Inkonsistenzen unbemerkt zu verbergen.

• Konfigurieren Sie read_only to 1 auf der Replikatinstanz, um unbeabsichtigte Zeilenänderungen zu verhindern.

• Stellen Sie innodb_flush_log_at_trx_commit 1 auf der Replikatinstanz auf.

• Auf sync_binlog der primären Instanz 1 auf gesetzt.

• Überprüfen Sie die Parität des Tabellenschemas zwischen der Primärdatei und dem Replikat.

• Stellen Sie sicher, dass replizierte Tabellen Primärschlüssel haben.