Pourquoi ma tâche AWS DMS CDC a-t-elle échoué avec « Erreur 1236 » alors que j'ai utilisé MySQL comme source ?

Brève description

AWS DMS vous permet d'effectuer des migrations ponctuelles et de répliquer les modifications en cours pour synchroniser les sources et les cibles. Pour lire les modifications en cours depuis la base de données source, AWS DMS utilise des actions d'API spécifiques au moteur pour lire les journaux de transactions du moteur source. Lorsque vous utilisez MySQL comme source, AWS DMS lit les modifications dans les journaux binaires basés sur les lignes (binlogs). AWS DMS migre ensuite ces modifications vers la cible.

En cas de problème avec les journaux binaires, le message « Erreur 1236 » s'affiche. Assurez-vous de configurer correctement tous les paramètres de journalisation binaires pour prendre en charge AWS DMS CDC lorsque vous utilisez une base de données autogérée ou compatible avec MySQL gérée par AWS.

Résolution

Pour résoudre le problème « Erreur 1236 », effectuez les actions suivantes en fonction du message d'erreur que vous recevez.

« Could not find first log file name in binary log index file reading binlog »

Exemple d'erreur provenant des journaux de tâches :

[SOURCE_CAPTURE  ]I: Setting position in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:886)
[SOURCE_CAPTURE  ]I: Position was set in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]E: Error 1236 (Could not find first log file name in binary log index file) reading binlog [1020493]
[TASK_MANAGER    ]I: Task - ABCDXXXXXXXXXXXXXX is in ERROR state, updating starting status to AR_NOT_APPLICABLE

L'erreur précédente se produit lorsque la base de données MySQL source a supprimé le journal binaire utilisé par AWS DMS pour répliquer les modifications de données vers la cible. MySQL peut supprimer le journal binaire pour les raisons suivantes :

• La période de conservation du journal binaire est trop faible.
• La tâche AWS DMS est bloquée ou arrêtée en raison d'un problème.

Pour vérifier si le journal binaire est disponible, exécutez la commande suivante pour répertorier tous les fichiers journaux binaires :

mysql> SHOW BINARY LOGS;

Puis, exécutez la commande suivante pour répertorier le fichier journal binaire actuel et sa position :

mysql> SHOW MASTER STATUS;

Pour plus d'informations sur les commandes précédentes, consultez les instructions SHOW BINARY LOGS et SHOW MASTER STATUS sur le site Web de MySQL.

Pour résoudre l'erreur, vérifiez la période de conservation des journaux binaires sur la base de données MySQL source. Si nécessaire, augmentez la période de conservation. Redémarrez la tâche AWS DMS pour exécuter à nouveau la phase de chargement complet.

Puis, effectuez les actions suivantes en fonction de votre type de base de données.

Bases de données MySQL autogérées

Pour vérifier la période de conservation des journaux binaires sur site ou Amazon Elastic Compute Cloud (Amazon EC2), vérifiez la valeur de expire_logs_days. Pour plus d'informations, consultez la page Expiration des logs (jours) sur le site Web de MySQL.

Remarque : il est recommandé de définir le paramètre global de la variable SET sur 1 ou plus. Pour plus d'informations, consultez la page Syntaxe SET pour l'attribution de variables sur le site Web de MySQL.

Bases de données MySQL gérées par AWS

Vérifiez les heures de conservation des journaux binaires définies sur une base de données Amazon Relational Database Service (Amazon RDS) pour MySQL ou Amazon Aurora édition compatible avec MySQL. Exécutez la commande suivante :

mysql> call mysql.rds_show_configuration;

Pour augmenter la durée de conservation des journaux à 24 heures, exécutez la commande suivante :

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

« Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master... »

Exemple d'erreur provenant des journaux de tâches :

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin.056367' at 787323674  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]D:  net_safe_read error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.)  (mysql_endpoint_capture.c:1119)
[SOURCE_CAPTURE  ]I:  Error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.) reading binlog. Try reconnect  (mysql_endpoint_capture.c:1123)

L'erreur précédente peut se produire pour les raisons suivantes :

• Une ligne contient plus de données que la valeur de max_allowed_packet sur la source. Pour plus d’informations, consultez la page paquet maximal autorisé sur le site Web de MySQL.
• Une transaction unique contient de grandes quantités de données ou plusieurs lignes sont mises à jour au cours d'une seule transaction.
• Le journal binaire de la base de données source est corrompu.

Si vous utilisez des colonnes d'objets binaires de grande taille (BLOB) ou de longues chaînes, définissez la valeur de max_allowed_packet sur le BLOB le plus grand utilisé. Ce paramètre peut avoir une valeur allant jusqu'à 1 Go. Pour plus d'informations, consultez la page Types BLOB et TEXT sur le site Web de MySQL.

Pour vérifier la taille de votre transaction la plus importante, consultez vos journaux binaires. Assurez-vous que la taille de la transaction ne dépasse pas la taille de max_allowed_packet. Pour plus d'informations sur la procédure de fractionnement d’une transaction importante, consultez la page Paquet trop volumineux sur le site Web de MySQL.

Si l'erreur persiste, il est possible que les journaux binaires sources soient corrompus.

Pour vérifier l'absence de problèmes dans les journaux binaires, procédez comme suit :

1. Exécutez la commande suivante pour vérifier si le journal binaire existe :

   mysql> SHOW BINARY LOGS;

2. Pour afficher les événements dans le journal binaire, exécutez la commande suivante :

   mysql> SHOW BINLOG EVENTS IN 'binlog file' FROM position;

   Remarque : remplacez binlog file par le nom du journal binaire et position par la position à laquelle l'événement se produit.

3. Pour télécharger les journaux binaires, exécutez la commande suivante :

   shell> mysqlbinlog \
       --read-from-remote-server \
       --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
       --port=3306  \
       --user ReplUser \
       --password \
       --raw \
       --verbose \
       --result-file=/tmp/ \
       binlog.00098

4. Vérifiez que le journal binaire mentionné dans le message d'erreur n'est pas corrompu.

5. Si le journal binaire est endommagé, créez un dossier AWS Support.

« Binlog truncated in the middle of event; consider out of disk space on master... »

Exemple d'erreur provenant des journaux de tâches :

[SOURCE_CAPTURE ]I: Read next binary log event failed; net_safe_read error 1236 (binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin-changelog.017672' at 486, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 125, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 4756.) (mysql_endpoint_capture.c:1069)
[SORTER ]I: Transaction consistency reached (sorter_transaction.c:347)
[TASK_MANAGER ]I: Starting replication now (replicationtask.c:2774)
[TASK_MANAGER ]I: Task - MGLVRIRUJH6FE2GP6F7SW46BPBW6YKF2JUJPSVY is in RUNNING state, updating starting status to AR_RUNNING (repository.c:5110)

L'erreur précédente peut se produire pour les raisons suivantes :

• Il y a un sync_binlog != 1 sur le serveur principal. Cela signifie que les événements du journal binaire peuvent ne pas être synchronisés sur le disque. Pour plus d'informations, consultez la page sync_binlog sur le site Web de MySQL.
• Le journal binaire de la base de données source est corrompu.

Pour résoudre cette erreur, assurez-vous que la valeur du paramètre sync_binlog de la source est définie sur 1. Puis, redémarrez la tâche.

Si le paramètre sync_binlog est déjà défini sur 1, vérifiez que le journal binaire n'est pas corrompu. Pour obtenir des instructions, reportez-vous à la section précédente « Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master... ».

« Client requested master to start replication from impossible position »

Exemple d'erreur provenant des journaux de tâches :

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin-changelog.007989' at 1631  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.)  (mysql_endpoint_capture.c:1053)
[SOURCE_CAPTURE  ]D:  Error reading binary log. [1020493]  (mysql_endpoint_capture.c:3995)
[SOURCE_CAPTURE  ]E:  Error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.) reading binlog events [1020493]  (mysql_endpoint_capture.c:1074)

Cette erreur se produit lorsque le serveur de base de données MySQL source s'arrête de manière inattendue. Un arrêt inattendu peut survenir en raison d'une panne matérielle telle qu'une erreur de disque ou une coupure de courant.

Pour résoudre cette erreur, effectuez l'une des actions suivantes en fonction de votre type de tâche AWS DMS :

• Pour les tâches de chargement complet et les tâches CDC, redémarrez la tâche AWS DMS.
• Pour les tâches CDC uniquement, démarrez la tâche AWS DMS à partir de la position de journal binaire suivante.

« Client requested master to start replication from position > file size »

Exemple d'erreur provenant des journaux de tâches :

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'binlog.000012' at 2179  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from position > file size)  (mysql_endpoint_capture.c:1052

Cette erreur peut se produire en raison de journaux binaires chiffrés. Si votre base de données MySQL source exécute MySQL version 8.0 et que vous chiffrez les journaux binaires, AWS DMS ne peut pas lire les journaux lors de l'initialisation de la tâche. Par conséquent, AWS DMS journalise cette erreur. Lorsque vous activez le chiffrement binaire des journaux, vous ne pouvez pas utiliser la réplication CDC qui utilise MySQL 8.0 comme source. Pour plus d'informations, consultez la page Chiffrement des fichiers journaux binaires et des fichiers journaux de relais sur le site Web de MySQL.

Afin de résoudre ce problème, procédez comme suit :

1. Exécutez la commande suivante pour vérifier votre version de MySQL :

   mysql> SELECT VERSION();

2. Exécutez la commande suivante pour vérifier si binlog_encryption est défini sur ON :

   mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'binlog_encryption';

3. Pour désactiver binlog_encryption, exécutez la commande suivante :

   mysql> SET GLOBAL binlog_encryption = OFF;

   -ou-
   Démarrez la tâche AWS DMS avec binlog_encryption désactivé, puis exécutez la commande suivante pour activer binlog_encryption :

   mysql> SET GLOBAL binlog_encryption = ON;

Informations connexes

Comment résoudre les erreurs de journalisation binaire que je reçois lorsque j'utilise AWS DMS avec Aurora compatible avec MySQL comme source ?