Risoluzione dei problemi di replica dovuti alla mancanza di record

Quando si utilizza Amazon RDS for MySQL o MariaDB con replica binaria dei log, è possibile che si verifichino errori di replica in cui il processo si interrompe a causa della mancanza di record nelle repliche di lettura. Questa sezione spiega come diagnosticare e risolvere questi problemi.

Cause comuni

Un'incoerenza dei dati tra l'origine e la replica potrebbe essere causata da uno dei seguenti scenari:

• Modifica manuale dei dati sulla replica

• Transazioni ignorate utilizzando sql_replica_skip_counter (sql_slave_skip_counterprima di MySQL 8.0.26)

• Righe mancanti sulla replica durante la sincronizzazione iniziale dei dati tramite strumenti di migrazione

Identificazione del problema

Un indicatore comune di questo problema è Error 1032 rappresentato dal messaggioCan't find record. Il seguente messaggio di errore viene visualizzato nel registro degli errori della replica:

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

Nota

Il formato del registro degli errori varia tra i motori MySQL e MariaDB. Per informazioni su come recuperare i log, consulta. Visualizzazione ed elenco dei file di log del database

Diagnosi del problema

Per diagnosticare l'errore di replica:

• Esamina i log degli errori di replica per identificare dove si è interrotta la replica. È possibile utilizzare MY-010584 come parola chiave di ricerca.

• Esegui SHOW REPLICA STATUS\G (SHOW SLAVE STATUS\Gprima di MySQL 8.0.22) sulla replica e rivedi la colonna: 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.

• Controlla il nome del file di registro binario e la posizione in cui il processo di replica si è interrotto sull'istanza di replica. È possibile trovare queste informazioni nel registro degli errori dell'istanza di replica.

Analisi dei log binari

Per esaminare un errore di replica in una transazione specifica, è possibile utilizzare l'mysqlbinlogutilità per esaminare il file di registro binario. Ad esempio, se la replica non riesce in end_log_pos una posizione 899 nel file di log binariomysql-bin-changelog.031523, è possibile analizzare questa posizione specifica per identificare la causa dell'errore.

Nota

Il end_log_pos valore indica la posizione finale dell'evento non riuscito. Nell'output del log binario decodificato, cercate l'evento che end_log_pos corrisponde a questo valore.

Utilizzate l'mysqlbinlogutilità per scaricare ed esaminare il registro binario pertinente. Usa l'endpoint per l'istanza principale.

$ 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

Nota

L'mysqlbinlogutilità è uno strumento MySQL nativo che consente di leggere e interpretare i contenuti dei log binari. Per ulteriori informazioni sull'accesso ai log binari su Amazon RDS, consulta. Accesso ai log binari MySQL

Il log binario dell'istanza writer mostra che l'istanza writer ha tentato di aggiornare un record conid=1: test_replication.users

#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

I log degli errori della replica mostrano che la replica non è riuscita a eseguire l'UPDATEistruzione perché il record di destinazione non esiste:

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

Per verificare che la riga sia mancante, controlla se la riga specifica esiste nella replica:

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

Questo output conferma che l'UPDATEoperazione dall'istanza DB di origine non è riuscita a replicarsi perché la riga di destinazione non esiste nella replica.

Evitare gli errori di replica

Consigliamo le seguenti best practice per evitare incoerenze di replica:

• Usa la replica. GTID-based Per ulteriori informazioni, consulta Utilizzo della GTID-based replica.

• Usa binlog_format come ROW sull'istanza principale. Con binlog_format asMIXED, c'è la possibilità che la replica nasconda silenziosamente le incongruenze.

• Configura 1 su sull'istanza read_only di replica per evitare modifiche involontarie alle righe.

• Impostato 1 su sull'innodb_flush_log_at_trx_commitistanza di replica.

• Imposta sync_binlog su 1 sull'istanza principale.

• Verifica la parità dello schema della tabella tra il primario e la replica.

• Assicurati che le tabelle replicate abbiano chiavi primarie.