Dépannage de la réplication entrante

Résolvez les problèmes détectés avec la réplication entrante.

Correction des erreurs de réplication entrante

Isolez les erreurs de réplication entrante en extrayant les informations connexes.

Utilisation de l'interpréteur de commandes MySQL

Utilisez l'interpréteur de commandes MySQL ou un programme client MySQL pour extraire les informations relatives à la réplication entrante.

Cette tâche nécessite les éléments suivants :

Réplique de système de base de données en cours d'exécution.
L'interpréteur de commandes MySQL ou un programme client MySQL est connecté au système de base de données de réplique.

Exécutez une ou plusieurs des commandes suivantes sur la réplique du système de base de données pour extraire des informations relatives à la réplication entrante :

SHOW REPLICA STATUS \G
Affiche des informations de statut sur les paramètres essentiels des unités d'exécution de la réplique. Voir SHOW REPLICA STATUS.
SELECT * FROM performance_schema.replication_connection_status \G
Affiche le statut courant de l'unité d'exécution d'E/S qui gère la connexion de la réplique à la source. Voir replication_connection_status.
SELECT * FROM performance_schema.replication_applier_status_by_worker \G
Affiche les détails des transactions traitées par les unités d'exécution du demandeur sur une réplique. Voir 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 d'utilisateur ou le mot de passe source est incorrect. Vérifiez vos données 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 actions suivantes : Spécifiez le même nom d'utilisateur dans `DEFINER` et Nom d'utilisateur du demandeur. Vous avez besoin du privilège `SET_USER_ID` uniquement lorsque les noms d'utilisateur dans `DEFINER` et Nom d'utilisateur du demandeur sont différents. Voir Création d'un canal de réplication. Communiquez avec Oracle Support pour accorder le privilège `SET_USER_ID` au nom d'utilisateur du demandeur.
`MY-1236: ER_MASTER_FATAL_ERROR_READING_BINLOG Got fatal error %d from master when reading data from binary log: '%s'`	Voir 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 requiert 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 la liste complète des messages d'erreur MySQL, voir Informations de référence sur les messages d'erreur du serveur.

Codes d'erreur du demandeur de réplication entrante

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

Tableau 22-5 Codes d'erreur du demandeur 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 être le cas si les données de la réplique ont été modifiées manuellement, par exemple. Pour corriger ces erreurs, vous devez resynchroniser la source et la réplique, puis effectuer une reprise du canal de réplication.
`MY-1205: ER_LOCK_WAIT_TIMEOUT`	Temporisation dépassée. Pour corriger cette erreur, effectuez une reprise le canal de réplication. Voir Reprise d'un canal
`MY-1595/ MY-013121: RELAY LOG READ FAILURE`	Le journal de relais est corrompu et ne peut pas être lu. Pour corriger cette erreur, réinitialisez le canal de réplication. Voir 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 être le cas si les données de la réplique ont été modifiées manuellement, par exemple.

Pour corriger ces erreurs, vous devez resynchroniser la source et la réplique, puis effectuer une reprise du canal de réplication.

MY-1205: ER_LOCK_WAIT_TIMEOUT Temporisation dépassée. Pour corriger cette erreur, effectuez une reprise le canal de réplication. Voir Reprise d'un canal

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

Pour la liste complète des messages d'erreur MySQL, voir Informations de référence sur les messages d'erreur du serveur.

Résolution de l'erreur fatale 1236

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

Utilisation de l'interpréteur de commandes MySQL

Utilisez l'interpréteur de commandes MySQL pour résoudre le problème Fatal Error 1236 que vous obtenez lors de l'exécution de la réplication entrante.

Cette tâche suppose ce qui suit :

Vous obtenez l'erreur fatale 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 jeu de GTID contenant les transactions déjà reçues, validées ou les deux. La source répond en envoyant toutes les transactions enregistrées dans son journal binaire dont le GTID ne figure pas dans le jeu de GTID envoyé par la réplique. Cet échange garantit que la source envoie uniquement les transactions ayant un GTID que la réplique n'a pas encore enregistré ou validé.

Effectuez les opérations suivantes pour résoudre le problème :

Pour appliquer le jeu GTID lors du chargement, utilisez l'option updateGtidSet: "append" dans la commande loadDump() de l'interpréteur de commandes MySQL. Voir Utilitaire de chargement de vidage de l'interpréteur de commandes MySQL.
Vérifiez et augmentez la configuration du journal d'expiration de la source pour garantir un délai suffisant pour le transfert des données vers la réplique. Voir binlog_expire_logs_seconds et expire_logs_days.

Résolution des problèmes de synchronisation des répliques et des sources

Vous obtenez les problèmes de synchronisation lorsque la réplique est loin derrière la source et que la réplication est irrécupérable.

Note

Avant de tenter une récupération après la survenue de cette erreur, il est recommandé de comprendre pourquoi cette erreur s'est produite et de prendre des mesures correctives.

Utilisation de l'interpréteur de commandes MySQL

Utilisez l'interpréteur de commandes MySQL pour résoudre les problèmes de synchronisation de la réplique et de la source.

Cette tâche suppose ce qui suit :

Votre source de réplication entrante et votre réplique ne sont plus synchronisées, la réplique a pris beaucoup de retard par rapport à la source et la réplication est irrécupérable.

Note

Si les valeurs GTID de la sources sont réinitialisées à une valeur inférieure à celles de la réplique, si une commande reset master a été émise sur la source par erreur, par exemple, la réplication entrante n'est pas récupérable. Dans ce scénario, vous devez recréer la configuration du système de base de données et de la réplication entrante.

Procédez de la façon suivante pour resynchroniser la réplique avec la source :

Arrêtez le canal de réplication existant et mettez en pause toutes les transactions sur la source.
Exportez les données sources vers le stockage d'objets. Voir Exportation d'une instance MySQL.
Supprimez les anciens objets de base de données et les bases de données existantes sur la réplique.
Importez le vidage du stockage d'objets dans le système de base de données. Voir Importation à l'aide de l'interpréteur de commandes MySQL.
Récupérez la valeur gtidExecuted à partir de la réplique.
Récupérez la valeurgtidExecuted à partir du fichier @.json du vidage de la source.
Comparez la valeur gtidExecuted de la réplique à la valeur gtidExecuted du vidage de la source pour obtenir le delta gtidExecuted.
Par exemple, si la valeur gtidExecuted du vidage de la source est serverUUID : 1-2000 et que la valeur gtidExecuted de la réplique est serverUUID : 1-1000, le delta est 1001-2000.
Connectez-vous à la réplique à partir de la ligne de commande et appliquez le delta à la réplique à l'aide de la procédure stockée CALL sys.SET_GTID_PURGED("+<ServerUUID>:<DeltaValue>).
L'exemple suivant utilise le delta indiqué ci-dessus :
```
call sys.SET_GTID_PURGED("+<ServerUUID>:1001-2000")
```
Une fois le traitement terminé, effectuez une reprise du canal de réplication.

Documentation sur Oracle Cloud Infrastructure