Skip navigation links
MySQL 5.0 Reference Manual :: 6 Réplication de MySQL :: 6.10 Correction de problèmes courants
6.11 Rapporter des bugs de réplication »
Section Navigation      [Toggle]

6.10. Correction de problèmes courants

Si vous avez suivi les instructions, et que votre configuration de réplication ne fonctionne pas, commencez par supprimer les problèmes liés à l'utilisateur comme ceci :

  • Vérifiez les messages d'erreurs dans les logs. De nombreux utilisateurs ont perdu du temps en ne faisant pas cela en premier.

  • Est-ce que le maître enregistre dans le log binaire ? Vérifiez avec la commande SHOW MASTER STATUS. Si il le fait, la variable Position doit être non nulle. Si ce n'est pas le cas, vérifiez que vous avez donné au serveur l'option log-bin et que vous lui avez donné un server-id.

  • Est-ce que l'esclave fonctionne? Vérifiez le avec SHOW SLAVE STATUS. La réponse se trouve dans la colonne Slave_running. Si ce n'est pas le cas, vérifiez les options de l'esclave, et vérifiez le fichier de log d'erreurs.

  • Si l'esclave fonctionne, a-t-il établit une connexion avec le maître? Exécutez la commande SHOW PROCESSLIST, et recherchez un utilisateur avec la valeur system user dans la colonne User et none dans la colonne Host, et vérifiez la colonne State. Si elle indique connecting to master, vérifiez les droits de connexion pour l'utilisateur de réplication sur le serveur, ainsi que le nom de l'hôte, votre configuration DNS, le fonctionnement du maître, et si tout est OK, vérifiez le fichier de log d'erreurs.

  • Si l'esclave fonctionnait, mais s'est arrêté, vérifiez le résultat de la commande SHOW SLAVE STATUS, et vérifiez le fichier de log d'erreurs. Il arrive que certaines requêtes réussissent sur le maître mais échouent sur l'esclave. Cela ne devrait pas arriver si vous avez pris la bonne sauvegarde du maître, et que vous n'avez jamais modifié les données sur le serveur esclave, autrement que par le truchement de l'esclave de réplication. Si c'est le cas, c'est un bogue, et vous devez le rapporter. Voyez plus loin pour savoir comment rapporter un bogue.

  • Si une requête qui a réussit sur le maître, refuse de s'exécuter sur l'esclave, et qu'une synchronisation complète de la base ne semble pas possible, essayez ceci :

    1. Commencez par voir s'il n'y a pas de lignes différentes de celles du maître. Essayez de comprendre comment elle a plus se trouver là, effacez-la, et essayez de redémarrer l'esclave avec SLAVE START. (cela peut être un bug : lisez les logs sur le manuel MySQL, http://www.mysql.com/documentation, pour savoir si c'est un bug et s'il est corrigé).

    2. Si la solution ci-dessus ne fonctionne pas ou ne s'applique pas, essayez de comprendre si c'est risqué de faire une correction à la main (au besoin) puis, ignorez la prochaine requête du maître.

    3. Si vous avez décidé que vous pouvez vous passer de la prochaine requête, utilisez la commande suivante : 

      mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;
mysql> START SLAVE;

      La valeur de n doit être de 1 si la requête n'utilise pas de valeur AUTO_INCREMENT ou LAST_INSERT_ID(). Sinon, la valeur doit être de 2. La raison pour utiliser la valeur 2 pour les requêtes qui utilisent AUTO_INCREMENT ou LAST_INSERT_ID() est qu'elles requièrent deux lignes dans le log binaire.

    4. Si vous êtes sûrs que l'esclave est parfaitement synchronisé avec le maître, et que personne n'a mis à jour les tables impliquées, rapportez nous un bug.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.