Forums, scripts, cours, services pour webmaster, manuels (PHP, MySQL, HTML...) en français !
PHP / MySql
Recherche
 
ManuelPHP.com
FAQ de la réplication
<<<
Correction de problèmes courants Administration du serveur
>>>

4.10 Réplication de MySQL
4 Administration du serveur
 Manuel de Référence MySQL 4.1 : Version Française

Introduction à la réplication
Présentation de l'implémentation de la réplication
Comment mettre en place la réplication
Fonctionnalités de la réplication et problèmes connus
Options de réplication dans le fichier my.cnf
Commandes SQL liées à la réplication
FAQ de la réplication
->Correction de problèmes courants

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.
Lorsque vous avez épuisé toutes les possibilités, et qu'il n'y a pas d'erreur utilisateur impliquée, et que la réplication ne fonctionne plus du tout ou qu'elle est très instable, il est temps de préparer un rapport de bogues. Essayer de passer un peu de temps sur ce rapport pour en faire un bon. Idéalement, vous souhaitons recevoir un cas de test au format présenté dans le dossier mysql-test/t/rpl* , du dossier source. Si vous soumettez un test comme cela, vous pouvez vous attendre à recevoir un patch dans un ou deux journées, même si la durée de réaction peut varier en fonction de nombreux facteurs. La deuxième meilleure option est simplement d'écrire un programme qui va facilement configurer les arguments de connexion de votre maître et esclave, et qui va illustrer le problème sur nos systèmes. Vous pouvez l'exécuter en C ou en Perl, suivant votre langage de programmation.

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
    
Une fois que vous avez rassemblé les preuves du problème fantôme, essayez au maximum de l'isoler dans un cas de test. Puis, rapporter le problème à bugs@lists.mysql.com avec autant d'information possibles.

<< Correction de problèmes courants >>
FAQ de la réplication Réplication de MySQL Administration du serveur





Google

Services webmasters

Les manuels
 

ManuelPHP.com © 2003-2012 Tigersun - Crédits
Webmaster Site Internet - Télécharger des Logiciels - Programme TV - Entraide Informatique - Agence de Communication
2017-06-23