Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# 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_counter`prima 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 messaggio`Can'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](USER_LogAccess.Procedural.Viewing.md)
## 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\G`prima 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'[`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html)utilità 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 binario`mysql-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'`mysqlbinlog`utilità per scaricare ed esaminare il registro binario pertinente. Usa l'endpoint per l'istanza principale.
```
$ mysqlbinlog --read-from-remote-server \
--host= \
--port=3306 \
--user= \
--password= \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name
```
**Nota**
L'`mysqlbinlog`utilità è 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](USER_LogAccess.MySQL.Binarylog.md)
Il log binario dell'istanza writer mostra che l'istanza writer ha tentato di aggiornare un record con`id=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='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
```
I log degli errori della replica mostrano che la replica non è riuscita a eseguire l'`UPDATE`istruzione 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'`UPDATE`operazione 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](mysql-replication-gtid.md).
+ Usa `binlog_format` come `ROW` sull'istanza principale. Con `binlog_format` as`MIXED`, 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_commit`istanza 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.