Dépannage de la réplication entrante

Résolvez les problèmes rencontrés lors de la réplication entrante.

Dépannage des erreurs de réplication entrante

Isolez les erreurs de réplication entrante en extrayant les informations relatives à cette dernière.

A l'aide de MySQL Shell

Utilisez le shell MySQL ou un programme client MySQL pour extraire les informations relatives à la réplication entrante.

Cette tâche requiert les éléments suivants :

Système de base de données de réplique en cours d'exécution.
MySQL Shell ou programme client MySQL connecté au système de base de données de la réplique.

Exécutez au moins une des commandes suivantes sur le système de base de données de réplique pour extraire les informations relatives à la réplication entrante :

SHOW REPLICA STATUS \G
Affiche les informations de statut de paramètres essentiels des threads de réplique. Reportez-vous à SHOW REPLICA STATUS.
SELECT * FROM performance_schema.replication_connection_status \G
Affiche le statut actuel du thread d'E/S qui gère la connexion de la réplique à la source. Reportez-vous à replication_connection_status.
SELECT * FROM performance_schema.replication_applier_status_by_worker \G
Affiche les détails des transactions gérées par les threads d'applicateur sur une réplique. Reportez-vous à replication_applier_status_by_worker.

Codes d'erreur du récepteur de réplication entrante

Ce tableau présente certains des codes d'erreur courants du récepteur de réplication entrante.

Tableau 22-4 Codes d'erreur du récepteur de réplication entrante

Code d'erreur	Description :
`MY-1045: ER_ACCESS_DENIED_ERROR; Access denied for user '%s'@'%s'`	Le nom utilisateur ou le mot de passe utilisé pour accéder à la source est incorrect. Vérifiez les informations d'identification. L'utilisateur n'est pas autorisé à accéder à la source. Vérifiez la source et assurez-vous que l'utilisateur de réplication est correctement configuré.
`MY-1227 (42000): Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) for this operation`	Vous pouvez effectuer l'une des opérations suivantes : Indiquez le même nom utilisateur dans `DEFINER` et Nom utilisateur d'applicateur. Vous avez besoin du privilège `SET_USER_ID` uniquement lorsque les noms utilisateur dans `DEFINER` et Nom utilisateur de l'applicateur sont différents. Reportez-vous à Création d'un canal de réplication. Contactez le support technique Oracle pour accorder le privilège `SET_USER_ID` au nom utilisateur de l'applicateur.
`MY-1236: ER_MASTER_FATAL_ERROR_READING_BINLOG Got fatal error %d from master when reading data from binary log: '%s'`	Reportez-vous à Résolution de l'erreur fatale 1236.
`MY-2003: Network connection has been refused`	Le nom d'hôte et le port sont incorrects ou la source n'est pas en cours d'exécution. Vérifiez le nom d'hôte et le port que vous avez définis et assurez-vous que la source est en cours d'exécution.
`MY-3159: ER_SECURE_TRANSPORT_REQUIRED Connections using insecure transport are prohibited while --require_secure_transport=ON`	La source nécessite une connexion sécurisée. Vérifiez que vous avez sélectionné l'une des options SSL lorsque vous avez défini votre canal.

Pour obtenir la liste complète des messages d'erreur MySQL, reportez-vous à Référence des messages d'erreur de serveur.

Codes d'erreur de l'applicateur de réplication entrante

Ce tableau présente certains des codes d'erreur courants de l'applicateur de réplication entrante.

Tableau 22-5 Codes d'erreur de l'applicateur de réplication entrante

Code d'erreur Description :

Code d'erreur	Description :
`MY-1146: ER_NO_SUCH_TABLE;` `MY-1032: HA_ERR_KEY_NOT_FOUND` `MY-1062: HA_ERR_FOUND_DUPP_KEY` `MY-1064: ERROR IN SQL syntax` `MY-1050: ER_TABLE_EXISTS_ERROR` `MY-1051: ER_BAD_TABLE_ERROR` `MY-1146: ER_NO_SUCH_TABLE` `MY-1007: ER_DB_CREATE_EXISTS` `MY-1054: ER_BAD_FIELD_ERROR`	Ces erreurs se produisent si les données de la réplique ne sont plus synchronisées avec la source. Cela peut par exemple se produire si les données de la réplique ont été modifiées manuellement. Pour corriger ces erreurs, vous devez resynchroniser la source et la réplique, puis reprendre le canal de réplication.
`MY-1205: ER_LOCK_WAIT_TIMEOUT`	Délai dépassé. Pour corriger cette erreur, reprenez le canal de réplication. Reportez-vous à Reprise d'un canal.
`MY-1595/ MY-013121: RELAY LOG READ FAILURE`	Le journal de relais est endommagé et ne peut pas être lu. Pour corriger cette erreur, réinitialisez le canal de réplication. Reportez-vous à Réinitialisation d'un canal.

MY-1146: ER_NO_SUCH_TABLE;
MY-1032: HA_ERR_KEY_NOT_FOUND
MY-1062: HA_ERR_FOUND_DUPP_KEY
MY-1064: ERROR IN SQL syntax
MY-1050: ER_TABLE_EXISTS_ERROR
MY-1051: ER_BAD_TABLE_ERROR
MY-1146: ER_NO_SUCH_TABLE
MY-1007: ER_DB_CREATE_EXISTS
MY-1054: ER_BAD_FIELD_ERROR

Ces erreurs se produisent si les données de la réplique ne sont plus synchronisées avec la source. Cela peut par exemple se produire si les données de la réplique ont été modifiées manuellement.

Pour corriger ces erreurs, vous devez resynchroniser la source et la réplique, puis reprendre le canal de réplication.

MY-1205: ER_LOCK_WAIT_TIMEOUT Délai dépassé. Pour corriger cette erreur, reprenez le canal de réplication. Reportez-vous à Reprise d'un canal.

MY-1595/ MY-013121: RELAY LOG READ FAILURE Le journal de relais est endommagé et ne peut pas être lu. Pour corriger cette erreur, réinitialisez le canal de réplication. Reportez-vous à Réinitialisation d'un canal.

Pour obtenir la liste complète des messages d'erreur MySQL, reportez-vous à Référence des messages d'erreur de serveur.

Résolution de l'erreur fatale 1236

Vous obtenez l'erreur lorsque l'ensemble GTID du vidage logique n'est pas appliqué sur le système de base de données ou que les journaux binaires ont été purgés de la source. Les fichiers journaux binaires sont indispensables pour la réplication.

A l'aide de MySQL Shell

Utilisez le shell MySQL pour résoudre le fichier Fatal Error 1236 obtenu lors de l'exécution de la réplication entrante.

Pour cette tâche, la ou les conditions suivantes doivent être réunies :

Vous obtenez l'erreur Fatal Error 1236 lors de l'exécution de la réplication entrante :

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting
      using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs
      containing GTIDs that the slave requires.

Lors de l'établissement de liaison de connexion initial, la réplique (système de base de données) envoie un ensemble GTID contenant les transactions qu'elle a déjà reçues et/ou validées. La source répond en envoyant toutes les transactions enregistrées dans son fichier journal binaire dont le GTID n'est pas inclus dans l'ensemble GTID envoyé par la réplique. Cet échange garantit que la source envoie uniquement les transactions dont le GTID n'a pas encore été enregistré ou validé par la réplique.

Pour résoudre le problème, procédez comme suit :

Pour appliquer l'ensemble GTID lors du chargement, utilisez l'option updateGtidSet: "append" dans la commande loadDump() de MySQL Shell. Reportez-vous à Utilitaire de chargement de fichier dump MySQL Shell.
Vérifiez et augmentez la configuration du délai d'expiration de fichier journal de la source afin de vous assurer que le transfert des données vers la réplique bénéficie d'un délai suffisant. Reportez-vous à binlog_expire_logs_seconds et à expire_logs_days.

Résolution des problèmes de synchronisation entre la réplique et la source

Vous obtenez les problèmes de synchronisation lorsque la réplique est très en retard par rapport à la source et que la réplication est irrécupérable.

Remarque

Avant toute tentative de récupération suite à l'erreur, il est recommandé d'examiner les causes possibles de l'erreur et d'effectuer des actions correctives.

A l'aide de MySQL Shell

Utilisez le shell MySQL pour résoudre les problèmes de synchronisation de la réplique et de la source.

Pour cette tâche, la ou les conditions suivantes doivent être réunies :

Votre source et votre réplique de réplication entrante ne sont plus synchronisées, la réplique est très en retard par rapport à la source et la réplication est irrécupérable.

Remarque

Si les valeurs gtid de la source sont réinitialisées sur une valeur inférieure à celle des valeurs gtid de la réplique, si une instruction reset master erronée a été émise sur la source par exemple, la réplication entrante n'est pas récupérable. Dans ce cas, recréez la configuration du système de base de données et de la réplication entrante.

Pour resynchroniser la réplique avec la source, procédez comme suit :

Arrêtez le canal de réplication existant et mettez en pause toutes les transactions sur la source.
Exportez les données source vers le stockage d'objet. Reportez-vous à la section Export d'une instance MySQL.
Enlevez les anciens objets de base de données et les bases de données pré-existantes sur la réplique.
Importez le fichier dump d'Object Storage vers le système de base de données. Reportez-vous à Import à l'aide du shell MySQL.
Extrayez la valeur gtidExecuted de la réplique.
Extrayez la valeur gtidExecuted du fichier dump @.json source.
Comparez la valeur gtidExecuted de la réplique à celle du fichier dump source pour obtenir la valeur delta gtidExecuted.
Par exemple, si la valeur gtidExecuted du fichier dump source est serverUUID:1-2000 et que celle de la réplique est serverUUID:1-1000, la valeur delta est 1001-2000.
Connectez-vous à la réplique à partir de la ligne de commande et appliquez la valeur delta à la réplique à l'aide de la procédure stockée CALL sys.SET_GTID_PURGED("+<ServerUUID>:<DeltaValue>).
Par exemple, en utilisant la valeur delta indiquée dans l'exemple précédent :
```
call sys.SET_GTID_PURGED("+<ServerUUID>:1001-2000")
```
Une fois le processus terminé, reprenez le canal de réplication.

Documentation Oracle Cloud Infrastructure