Bonjour,
J'ai un énorme soucis et je ne trouve aucune réponse à mon problème de réplication...
J'ai 2 serveurs sous Debian : un maître et un esclave. La réplication marchait très bien jusqu'à ce que la base de données mysql plante.
Maintenant, l'esclave ne veut plus du tout se connecter au maître...
J'ai tout vérifié :
- j'ai testé le ping du nom de machine du maitre (du cote esclave), il trouve son adresse IP mais le ping ne marche pas.
- J'ai pingué le nom de machine de l'esclave (du cote maitre) et là tout marche.
J'ai vérifié les fichiers de configuration :
Sur le maitre :
- server_id = 1
- port = 3306
Sur l'esclave :
- server_id = 2
- port_master = 3306
L'utilisateur qui a été paramétré à les droits suivant sur le maître : Select_priv, Reload_priv, Super_priv, Repl_slave_priv.
max_questions est à 0
max_updates = 0
max_connections = 0
Mes messages d'erreurs n'apparaissent que sur l'esclave, et les voici :
Jan 10 12:12:04 esclave mysqld[1527]: 070110 12:12:04 [ERROR] Slave I/O thread: error connecting to master 'repl@maitre:3306': Error: 'Lost connection to MySQL server during query' errno: 2013 retry-time: 60 retries: 86400
Jan 10 15:11:04 esclave mysqld[1527]: 070110 15:11:04 [ERROR] Slave I/O thread killed while connecting to master
Jan 10 15:11:04 esclave mysqld[1527]: 070110 15:11:04 [ERROR] Slave I/O thread exiting, read up to log 'maitre-bin.000036', position 57669
Jan 10 15:11:04 esclave mysqld[1527]: 070110 15:11:04 [ERROR] Error reading relay log event: slave SQL thread was killed
Jan 10 15:11:29 esclave mysqld[1527]: 070110 15:11:29 [Note] Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log './esclave-relay-bin.000001' position: 4
Jan 10 15:14:38 esclave mysqld[1527]: 070110 15:14:38 [ERROR] Slave I/O thread: error connecting to master 'repl@maitre:3306': Error: 'Lost connection to MySQL server during query' errno: 2013 retry-time: 60 retries: 86400
Jan 10 15:22:58 esclave mysqld[1527]: 070110 15:22:58 [ERROR] Slave I/O thread killed while connecting to master
Jan 10 15:22:58 esclave mysqld[1527]: 070110 15:22:58 [ERROR] Slave I/O thread exiting, read up to log 'FIRST', position 4
Jan 10 15:22:58 esclave mysqld[1527]: 070110 15:22:58 [ERROR] Error reading relay log event: slave SQL thread was killed
Jan 10 15:32:42 esclave mysqld[1527]: 070110 15:32:42 [Note] Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log './esclave-relay-bin.000001' position: 4
Jan 10 15:35:51 esclave mysqld[1527]: 070110 15:35:51 [ERROR] Slave I/O thread: error connecting to master 'repl@maitre:3306': Error: 'Lost connection to MySQL server during query' errno: 2013 retry-time: 60 retries: 86400
Quand je fais un PROCESSLIST sur l'esclave :
mysql> SHOW PROCESSLIST;
+-----+-------------+-------------------+----------+---------+------+-----------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+-------------+-------------------+----------+---------+------+-----------------------------------------------------------------------+------------------+
| 566 | system user | | NULL | Connect | 5803 | Connecting to master | NULL |
| 567 | system user | | NULL | Connect | 5803 | Has read all relay log; waiting for the slave I/O thread to update it | NULL |
+-----+-------------+-------------------+----------+---------+------+-----------------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)
Quand je fais PROCESSLIST sur le maitre, je ne vois rien en rapport avec la replication.
J'ai même regardé les ports :
Sur l'esclave :
esclave:# netstat -laputen | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 0 2014 1526/mysqld
tcp 0 1 192.168.1.3:32849 192.168.1.1:3306 SYN_SENT 103 32423 1526/mysqld
Sur le maitre
maitre:/var/log# netstat -laputen | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 0 32860729 836/mysqld
Après, j'ai testé les services mysql de 2 façons :
La première : j'ai fait un ps -e
Sur l'esclave :
esclave:/var/log# ps -e | grep mysql
1489 ? 00:00:00 mysqld_safe
1526 ? 00:00:00 mysqld
1528 ? 00:00:00 mysqld
1529 ? 00:00:00 mysqld
1530 ? 00:00:00 mysqld
1531 ? 00:00:00 mysqld
1532 ? 00:00:00 mysqld
1533 ? 00:00:00 mysqld
1534 ? 00:00:00 mysqld
1535 ? 00:00:00 mysqld
1536 ? 00:00:00 mysqld
3798 ? 00:00:00 mysqld
3799 ? 00:00:00 mysqld
Sur le maitre :
maitre:/var/log# ps -e | grep mysql
799 pts/0 00:00:00 mysqld_safe
836 pts/0 00:00:00 mysqld
838 pts/0 00:00:00 mysqld
839 pts/0 00:00:00 mysqld
840 pts/0 00:00:00 mysqld
841 pts/0 00:00:00 mysqld
842 pts/0 00:00:00 mysqld
843 pts/0 00:00:01 mysqld
844 pts/0 00:00:00 mysqld
845 pts/0 00:00:00 mysqld
846 pts/0 00:00:00 mysqld
847 pts/0 00:00:00 mysqld
..... (y'en a 83 de lancer)
La seconde : en faisant mysqladmin ping
Sur l'esclave :
esclave:/var/log# mysqladmin ping
mysqld is alive
Sur le maitre :
maitre:/var/log# mysqladmin ping
mysqld is alive
Je ne vois absolument pas comment regler ce problème, et mon patron va finir par m'en vouloir
SVP si quelqu'un a une idée ça serait génial !!!! Moi en tout cas j'en ai plus...
Forum Linux.debian/ubuntu La réplication : gros soucis
11
jan.
2007
# Thread
Posté par drakkar . Évalué à 2.
Je chercherais donc plus par là, sur le serveur.
Tu pourrais aussi voir sur : http://dev.mysql.com/doc/refman/5.0/fr/index.html
Je crois que la section 6 pourra te donner des idées à creuser.
Bon courage !
[^] # Re: Thread
Posté par morgane brocquevielle . Évalué à 1.
Merci quand même d'avoir répondu à mon message :D !
# telnet
Posté par Philippe Martin . Évalué à 1.
Depuis ta machine esclave :
telnet ip_maitre 3306
[^] # Re: telnet
Posté par morgane brocquevielle . Évalué à 1.
Et pareil du maitre vers l'esclave...
Mais j'ai regardé iptables, et il n'y a rien qui bloque ce port !!!! c'est ça que je ne comprends pas !
[^] # Re: telnet
Posté par drakkar . Évalué à 1.
il me semble que Philippe a raison, je me suis laissé abuser par mysqladmin ping qui stipule que LOCALEMENT chaque MySQL est actif.
Cependant tu nous montres grâce à netstat sur l'esclave que la communication vers maitre est initiée et ne passe pas.
De plus, au début, tu précises que le ping depuis esclave vers maitre ne passe pas non plus.
J'aurais tendance à y voir un signe que, sur maitre, les ports sont bloqués d'une façon ou d'une autre. Un firewall (iptables serait pourtant un bon candidat !) se met probablement en travers de ton chemin.
Tu peux aussi utiliser nc (netcat) en écoute sur un port 3333 par exemple, sur maitre. Ce doit être lancé par: nc -l -p 3333
De l'autre côté, sur esclave, tu tentes nc -p 3333 maitre et la communication doit s'établir. Si tu tapes alors "hello!" sur esclave, tu
doit voir ce texte sur maitre.
Bref, si cela ne fonctionne pas avec netcat, c'est bien un soucis de blocage au niveau réseau. Au moins, tu auras avancé et sauras que MySQL n'est pas la cause première de tes soucis. Peut-être qu'en postant ici les résultats de iptables -L sur chacune des machines on pourrait y voir quelque chose d'inattendu ?
Bon courage !
[^] # Re: telnet
Posté par morgane brocquevielle . Évalué à 1.
Je m'explique, quand je fais le tcpdump sur le maitre vers l'esclave il m'écrit :
maitre:~# tcpdump -v host 192.168.1.2
0 packets captured
345 packets received by filter
0 packets dropped by kernel
Par contre, quand je fais le même test du maitre vers toute autre machine alors là c'est niquel, ca me met :
345 packets captured
345 packets received by filter
0 packets dropped by kernel
Et de l'esclave vers le maitre c'est un bon résultat également !
C'est pour ça que je n'arrive pas à situer le problème....
[^] # Re: telnet
Posté par drakkar . Évalué à 1.
Selon ton netstat fait sur esclave, on dirait que 192.168.1.1 est maitre et 192.168.1.3 est esclave. Alors, je m'interroge maintenant: erreur de frappe, ou incohérence dans les IPs ?
La résolution de nom fait-elle bien correspondre les bonnes IPs aux bons noms ?
C'est peut-être simplement le tcpdump qui ne va pas ? :-)
[^] # Re: telnet
Posté par morgane brocquevielle . Évalué à 1.
Mais j'avais quand même fait le test sur la bonne adresse IP. Et ca n'a rien donné !
La résolution de nom fait bien correspondre les bonnes adresses IP aux bons noms...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.