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.
- 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.
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' |
|
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 :
|
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. |
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 : |
---|---|
|
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. |
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.
- 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 appliquer l'ensemble GTID lors du chargement, utilisez l'option
updateGtidSet: "append"
dans la commandeloadDump()
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.
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.
- 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.
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.