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_counteravant 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èmeCan'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, consultezListe et affichage des fichiers journaux de base de données.

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\Gversion 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'mysqlbinlogutilitaire pour examiner le fichier journal binaire. Par exemple, si la réplication a échoué à une end_log_pos position 899 dans le fichier journal binairemysql-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'mysqlbinlogutilitaire 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=<rds-endpoint> \
--port=3306 \
--user=<username> \
--password=<password> \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name

Note

L'mysqlbinlogutilitaire 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, consultezAccès aux journaux binaires MySQL.

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='[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

Les journaux d'erreurs de la réplique indiquent que la réplique n'a pas pu exécuter l'UPDATEinstruction 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'UPDATEopé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.

• À utiliser binlog_format comme ROW sur l'instance principale. Avec binlog_format asMIXED, il est possible que la réplication masque silencieusement les incohérences.

• read_onlyConfigurez-le 1 sur l'instance de réplication pour empêcher toute modification involontaire des lignes.

• innodb_flush_log_at_trx_commitDéfini 1 sur sur l'instance de réplique.

• sync_binlogDé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.