| 6 Réplication de MySQL
 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
 . Détails d'implémentation de la réplication
 . Comment mettre en place la réplication
 . Compatibilité de la réplication entre les versions de MySQL
 . Changer de version de réplication
 . Replication Features, Replication Options, Replication Upgrade, Replication
 . Options de démarrage de la réplication
 . FAQ de la réplication
 ->Correction de problèmes courants
 . Rapporter des bugs de réplication
 
 
 | 
  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 :  
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é).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,
utilisez la commande suivante :  
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.| 
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;mysql> START SLAVE;
 | 
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. |