Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes de réplication dus à des enregistrements manquants
Lorsque vous utilisez Amazon RDS for MySQL ou MariaDB avec la réplication de journaux binaires, vous pouvez rencontrer des échecs de réplication lorsque le processus s'arrête en raison d'enregistrements manquants lors de la lecture des répliques. Cette section explique comment diagnostiquer et résoudre ces problèmes.
## Causes courantes
Une incohérence des données entre la source et la réplique peut être due à l'un des scénarios suivants :
+ Modification manuelle des données sur la réplique
+ Transactions ignorées en utilisant `sql_replica_skip_counter` (`sql_slave_skip_counter`avant MySQL 8.0.26)
+ Lignes manquantes sur la réplique lors de la synchronisation initiale des données à l'aide des outils de migration
## Identifier le problème
Le message est un indicateur courant `Error 1032` de ce problème`Can't find record`. Le message d'erreur suivant apparaît dans le journal des erreurs de la réplique :
```
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
```
**Note**
Le format du journal des erreurs varie entre les moteurs MySQL et MariaDB. Pour plus d'informations sur la façon de récupérer les journaux, consultez[Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md).
## Diagnostiquer le problème
Pour diagnostiquer l'échec de réplication :
+ Consultez les journaux des erreurs de réplication pour identifier l'endroit où la réplication s'est arrêtée. Vous pouvez l'utiliser `MY-010584` comme mot-clé de recherche.
+ Exécutez `SHOW REPLICA STATUS\G` (`SHOW SLAVE STATUS\G`version antérieure à MySQL 8.0.22) sur la réplique et examinez la `Last_Error` colonne :
```
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.
```
+ Vérifiez le nom du fichier journal binaire et la position à laquelle le processus de réplication s'est arrêté sur l'instance de réplication. Vous pouvez trouver ces informations dans le journal des erreurs de l'instance de réplication.
## Analyse des journaux binaires
Pour examiner un échec de réplication lors d'une transaction spécifique, vous pouvez utiliser l'[`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html)utilitaire pour examiner le fichier journal binaire. Par exemple, si la réplication a échoué à une `end_log_pos` position `899` dans le fichier journal binaire`mysql-bin-changelog.031523`, vous pouvez analyser cet emplacement spécifique pour identifier la cause de l'échec.
**Note**
La `end_log_pos` valeur indique la position finale de l'événement défaillant. Dans la sortie du journal binaire décodé, recherchez l'événement `end_log_pos` correspondant à cette valeur.
Utilisez l'`mysqlbinlog`utilitaire pour télécharger et examiner le journal binaire correspondant. Utilisez le point de terminaison pour l'instance principale.
```
$ mysqlbinlog --read-from-remote-server \
--host= \
--port=3306 \
--user= \
--password= \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name
```
**Note**
L'`mysqlbinlog`utilitaire est un outil MySQL natif qui vous aide à lire et à interpréter le contenu binaire des journaux. Pour plus d'informations sur l'accès aux journaux binaires sur Amazon RDS, consultez[Accès aux journaux binaires MySQL](USER_LogAccess.MySQL.Binarylog.md).
Le journal binaire de l'instance d'écriture indique que l'instance d'écriture a tenté de mettre à jour un enregistrement avec `id=1` dans la `test_replication.users` table :
```
#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
```
Les journaux d'erreurs de la réplique indiquent que la réplique n'a pas pu exécuter l'`UPDATE`instruction car l'enregistrement cible n'existe pas :
```
Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND
```
Pour vérifier que la ligne est manquante, vérifiez si la ligne spécifique existe sur le réplica :
```
SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)
```
Cette sortie confirme que l'`UPDATE`opération depuis l'instance de base de données source n'a pas pu être répliquée car la ligne cible n'existe pas sur la réplique.
## Éviter les échecs de réplication
Nous recommandons les meilleures pratiques suivantes pour éviter les incohérences de réplication :
+ Utilisez GTID-based la réplication. Pour de plus amples informations, veuillez consulter [Utilisation de GTID-based la réplication](mysql-replication-gtid.md).
+ À utiliser `binlog_format` comme `ROW` sur l'instance principale. Avec `binlog_format` as`MIXED`, il est possible que la réplication masque silencieusement les incohérences.
+ `read_only`Configurez-le `1` sur l'instance de réplication pour empêcher toute modification involontaire des lignes.
+ `innodb_flush_log_at_trx_commit`Défini `1` sur sur l'instance de réplique.
+ `sync_binlog`Défini `1` sur sur l'instance principale.
+ Vérifiez la parité du schéma de table entre le principal et le réplica.
+ Assurez-vous que les tables répliquées possèdent des clés primaires.