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 . Fonctionnalités de la réplication et problèmes connus . 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.9 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 :
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.
- 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.
|