Discussion :

[patrick B]

Bonjour

Je suis en mysql 5.1.66 sous linux centos release 6.2

je dispose d'un master et de 7 esclaves dédiés.
Aprés avoir redémarré le serveur d'un des esclaves appellons-le E01R, ce dernier ne veut plus se répliquer sous l'odieux prétexte :

SLAVE I/O : Fatal error : the salve i/O thread stops because master and slave have equal mysql error ids; these ids must be different for replication to work error code 1593.

Or nous avons vérifié le server id du maitre, il est bien différent de l'esclave.

plusieurs actions ont été menés comme :

- modifier server id de l'esclave avec arrêt relance de l'esclave : KO

- effectuer des change master pour le faire démarrer sur une autre position (pas trop utile mais bon ..) : KO

- vérification des fichier *.cnf : sans résultats...

Je sèche : si vous avez des idées ...

merci bcp.

[Artemus24]

Salut patrick.

J'utilise MySql sous Wamp, mais sans faire de la réplication.
J'ai fait une petite recherche sur le net et il semble que le problème vienne du fichier "auto.cnf".

Voici ce qui est conseillé de faire :
1) arrêtez votre "slave".
2) arrêtez le service "mysqld".
3) copier le fichier "auto.cnf" au cas où.
4) détruisez ce fichier (il se trouve dans ".../mysql/mysql5.7.7/data")
5) relancez le service "mysqld".
6) redémarrez votre "slave'.

@+

[patrick B]

Merci de ta réponse mais malheureusement ce fichier n'existe pas dans ma version de mysql : 5.1.66

J'avais déjà lu ce post et j'ai quand même effectué une recherche de ce fichier.

Mais merci quand même..

Il va de soi que si je trouve de mon côté, je remplirai ce post.

Patrick

[patrick B]

Bonjour,

Nos avons trouvé :

Il faut comprendre que chaque serveur a une adresse ip + une adresse ip "virtuelle" utilisé pour la réplication et l'applicatif.

Hors lors du redémarrage du serveur esclave l'ip applicative a aussi été monté sur l'esclave.

Du coup l'esclave voulait s'auto répliquer...
D'ou l'erreur de la même ids.

Une fois identifié cette erreur nous avons démonté l'ip applicative du serveur esclave et ... la réplication a repris sans pbm...

Par contre nous sommes resté une semaine avec cette ip applicatve connecté sur les deux serveurs et ...
L'applicatif a inséré des données sur les DEUX serveurs...

[SQLpro]

hé oui... MySQL c'est de la m... Si vous aviez été avec SQL Server, cette mauvaise manip aurait été détecté dès la mise en route du réplica et aucune donnée n'aurait été dualisée.... Je vous souhaite bien du courage, car il est impossible de s'y retrouver.... Notamment pour les updates !

A +