Pourquoi ma tâche CDC AWS DMS a-t-elle échoué avec une erreur 1236 lors de l'utilisation de MySQL comme source ?

Brève description

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

L'erreur 1236 est due à des problèmes liés aux journaux binaires. Par conséquent, avant de procéder au dépannage, assurez-vous que l'ensemble des paramètres de journalisation binaire sont correctement configurés afin de prendre en charge la CDC AWS DMS. Pour plus d'informations, veuillez consulter les sections Utilisation d'une base de données compatible MySQL autogérée comme source pour AWS DMS et Utilisation d'une base de données compatible MySQL et gérée par AWS comme source pour AWS DMS.

Résolution

Suivez les étapes ci-dessous, en fonction de votre cas d'utilisation et de la cause de l'erreur.

Erreur 1236 (Impossible de trouver le nom du premier fichier journal dans le fichier d'index du journal binaire) lors de la lecture du journal binaire

Erreur dans les 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

Cette erreur indique que le journal binaire utilisé par AWS DMS pour répliquer les modifications de données sur la cible a été purgé de la base de données MySQL source. Cela se produit pour deux raisons :

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

Exécutez ces commandes pour confirmer si le journal binaire est disponible ou non.

Répertorier tous les fichiers journaux binaires :

mysql> SHOW BINARY LOGS;

Répertorier le fichier journal binaire actuel et sa position :

mysql> SHOW MASTER STATUS;

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

Suivez ces étapes, en fonction du type d'instance que vous utilisez.

Bases de données MySQL autogérées - Sur site ou Amazon Elastic Compute Cloud (Amazon EC2)

Vérifiez la valeur du paramètre expire_logs_days afin de vérifier la période de conservation des journaux binaires. Il est recommandé de définir ce paramètre sur une valeur supérieure ou égale à 1 au niveau global.

Bases de données MySQL gérées par AWS - Amazon Relational Database Service (Amazon RDS) for MySQL ou Amazon Aurora édition compatible avec MySQL

1.    Vérifiez les heures de conservation des journaux binaires définies sur la base de données MySQL en exécutant la commande mysql.rds_show_configuration :

mysql> call mysql.rds_show_configuration;

2.    Afin d'augmenter la période de conservation des journaux à 24 heures, exécutez la commande mysql.rds_set_configuration :

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

Erreur 1236 (l'entrée d'événement du journal a dépassé max_allowed_packet ; augmentez max_allowed_packet sur master ; ...)

Erreur dans les 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)

Cette erreur peut avoir deux causes :

1. La valeur du paramètre max_allowed_packet sur la source est inférieure à la taille des événements de journal binaire sur la source.
2. Le journal binaire est corrompu dans la base de données source.

Pour résoudre ces problèmes, procédez comme suit :

1.    Sur la source, définissez max_allowed_packet sur une valeur plus élevée. Ainsi, les tailles d'événements de journal binaire ne peuvent plus constituer la cause de l'erreur. Ce paramètre peut avoir une valeur allant jusqu'à 1 Go.

2. Si la définition d'une valeur max_allowed_packet plus élevée ne résout pas le problème, les journaux binaires de la source peuvent être corrompus. Le message d'erreur contient le texte suivant :

« the first event '/mnt/data/logs/mysql-bin.056367' at 123, the last event read from '/mnt/data/logs/mysql-bin.056367' at 787323693 » (le premier événement '/mnt/data/logs/mysql-bin.056367' à 123, le dernier événement lu depuis '/mnt/data/logs/mysql-bin.056367' à 787323693)

En conséquence, vérifiez la corruption de mysql-bin.056367 en exécutant ces commandes :

1.    Vérifiez si le journal binaire existe :

mysql> SHOW BINARY LOGS;

2.    Affichez les événements dans le journal binaire :

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

3.    Téléchargez les journaux binaires :

mysql> MYSQLBINLOG;

Erreur 1236 (journal binaire tronqué au milieu de l'événement ; considérez la possibilité d'un manque d'espace disque sur le master ; ...)

Erreur dans les 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)

Il existe deux causes principales de cette erreur :

1. Il existe 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.
2. Le journal binaire est corrompu dans la base de données source.

Pour résoudre cette erreur :

1.    Vérifiez la valeur du paramètre sync_binlog sur la source.

2.    Modifiez la valeur de sync_binlog et définissez-la sur 1.

3.    Redémarrez la tâche.

Remarque : si le paramètre sync_binlog est déjà défini sur 1, vérifiez le journal binaire afin de détecter toute corruption en suivant les étapes décrites précédemment pour l'erreur 1236 (l'entrée d'événement du journal a dépassé max_allowed_packet ; augmentez max_allowed_packet sur master ; ...)

Erreur 1236 (le client a demandé au master de démarrer la réplication à partir d'une position impossible...)

Erreur dans les 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 généralement si le serveur de base de données MySQL source s'arrête de manière inattendue. Cela peut être dû à une panne matérielle telle qu'une erreur de disque ou une coupure de courant.

Afin de résoudre cette erreur, procédez comme suit en fonction de votre type de tâche AWS DMS :

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

Erreur 1236 (le client a demandé au master de démarrer la réplication à partir d'une position > taille du fichier)

Erreur dans les 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 être causée par des journaux binaires cryptés. Si votre base de données MySQL source exécute MySQL version 8.0 et que les journaux binaires sont cryptés, AWS DMS ne peut pas lire les journaux lors de l'initialisation de la tâche. Par conséquent, AWS DMS consigne cette erreur. AWS DMS ne prend pas en charge la réplication CDC utilisant MySQL 8.0 comme source lorsque le chiffrement des journaux binaires est activé.

1.    Vérifiez votre version de MySQL :

mysql> SELECT VERSION();

2.    Vérifiez si le paramètre binlog_encryption est ON (ACTIVÉ) :

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

3.    Désactivez le chiffrement des journaux binaires :

mysql> SET GLOBAL binlog_encryption = OFF;

-ou-

Démarrez la tâche AWS DMS avec le paramètre binlog_encryption désactivé, puis activez-le :

mysql> SET GLOBAL binlog_encryption = ON;

---

Informations connexes

Comment puis-je dépanner des erreurs de journalisation binaire que j'ai reçues lors de l'utilisation d'AWS DMS avec Aurora MySQL comme source ?