6.10 Rapporter des bugs de réplication

Lorsque vous avez bien vérifié qu'il n'y a pas de problèmes avec les utilisateurs impliqués, et que la réplication ne fonctionne pas ou qu'elle est instable, il est temps d'envoyer un rapport de bug. Nous avons besoin d'autant d'information que possible pour rechercher le bug. N'hésitez pas à investir quelques efforts lors de la préparation d'u rapport de bug.

• Vérifiez qu'il n'y a pas d'erreur utilisateur impliquée. Par exemple, si vous modifiez l'esclave sans passer par le thread esclave, les données seront désynchroniséez et vous pourrez alors rencontrer des problèmes de contraintes de clés uniques durant les modifications. Dans ce cas, l'esclave doit être arrêté et nettoyé manuellement pour être synchronisé avec le maître. Ce n'est pas un problème de réplication : c'est un problème d'interference extérieure, qui conduit à l'échec de la réplication.
• Exécutez l'esclave avec les options --log-slave-updates et --log-bin . Elles font que l'esclave va enregistrer les modifications qu'il reçoit dans ses propres logs binaires.
• Sauvez toutes les preuves avant de remettre à zéro l'état de la réplication. Si vous n'avez aucune information, ou seulement des informations partielles, cela nous prendra plus de temps pour rechercher le problème. Les preuves que vous devez rassembler sont :
  • Tous les logs binaires du maître
  • Tous les logs binaires de l'esclave
  • Le résultat de la commande SHOW MASTER STATUS sur le maître au moment du problème.
  • Le résultat de la commande SHOW SLAVE STATUS sur l'esclave au moment du problème.
  • Les logs d'erreur du maître et de l'esclave.
• Utilisez mysqlbinlog pour éxaminer les logs binaires. La commande suivante doit permettre d'identifier la requête coupable :

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