4.10.8 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 :

• 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, as-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 :
  • Commencez par voir si il n'y a pas de lignes dans le chemin. Essayez de comprendre comment a plus se trouver la, effacez la, et essayer de redémarrer l'esclave avec SLAVE START
  • 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.
  • Si vous avez décidé que vous pouvez vous passer de la prochaine requête, exécutez les commandes SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; SLAVE START; pour ignorer toutes les requêtes qui n'utilisent pas AUTO_INCREMENT ou LAST_INSERT_ID() , ou SET GLOBAL SQL_SLAVE_SKIP_COUNTER=2; SLAVE START; . La raison pour laquelle des requêtes qui utilisent AUTO_INCREMENT or LAST_INSERT_ID() sont différentes, est que elles représentent deux événements dans le log binaire du maître.
  • Si vous êtes sûr que l'esclave a été démarré en parfaite synchronisation avec le maître, et que personne n'a fait de modification dans les tables impliquées, en dehors de l'esclave, lisez les rapport de bogues, pour vous éviter d'essayer tous les trucs ci-dessus.
• Assurez vous que vous ne rencontrez pas un des vieux bogues que vous pourriez supprimer en changeant de versions.
• Si tout cela échoue, lisez les logs d'erreurs. Si ils sont gros, utilisez la commande grep -i slave /path/to/your-log.err sur l'esclave. Il n'y a pas de schéma de recherche particulier a appliquer au maître, car les seules erreurs qu'il stocke sont des erreurs générales : si il le peut, il envoie l'erreur à l'esclave.

Si vous pouvez utiliser l'une des méthodes ci-dessus pour démontrer votre bogue, utilisez le script mysqlbug pour préparer le rapport de bogue, et envoyez le à bugs@lists.mysql.com . Si vous avez un problème fantôme (un bogue qui survient, mais que vous ne pouvez pas reproduire à coup sûr) :

• Vérifiez qu'il y n'y a pas d'autre utilisateur impliqué. Par exemple, si vous modifiez l'esclave en dehors du thread l'esclave, les données seront désynchronisées, et vous pourriez aboutir à des violations de contraintes, auquel cas, vous devez arrêter l'esclave et nettoyer manuellement les tables pour les synchroniser.
• Exécutez l'esclave avec les options log-slave-updates et log-bin -- cela va conserver un log de toutes les modifications dans le cadre de l'esclave.
• Sauvez toutes les preuves avant d'éteindre la réplication. Si nous n'avons que des informations schématiques, cela nous prendra beaucoup de temps pour étudier le problème. Les preuves que vous devriez obtenir sont :
  • Le fichier de log binaire du maître
  • Tous les fichiers de logs binaires sur l'esclave
  • Le résultat de la commande SHOW MASTER STATUS sur le maître, au moment de la découverte du problème.
  • Le résultat de la commande SHOW SLAVE STATUS sur le maître, au moment de la découverte du problème.
  • Les fichiers de log d'erreurs du maître et de l'esclave.
• Utilisez mysqlbinlog pour examiner les logs binaires. Cette instructions doit être pratique pour rechercher des requêtes problématiques :

  mysqlbinlog -j pos_from_slave_status /path/to/log_from_slave_status | head