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.
# 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_counter`vor 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 Nachricht`Can'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](USER_LogAccess.Procedural.Viewing.md)
## 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\G`vor 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 [`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html)Hilfsprogramm verwenden, um die binäre Protokolldatei zu untersuchen. Wenn die Replikation beispielsweise an einer `end_log_pos` Position `899` in der Binärprotokolldatei fehlgeschlagen ist`mysql-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= \
--port=3306 \
--user= \
--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 unter[Zugriff auf MySQL-Binärprotokolle](USER_LogAccess.MySQL.Binarylog.md).
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='updated4@example.com' /* 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='updated5@example.com' /* 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](mysql-replication-gtid.md).
+ Verwenden Sie `binlog_format` wie `ROW` auf der primären Instanz. Mit `binlog_format` as besteht bei der Replikation die Möglichkeit`MIXED`, 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.