Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Linux.debian : La réplication : gros soucis

Posté par morgane brocquevielle () le 11 janvier 2007
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...

> Lire le message (8 commentaires, moyenne: 1,1).  

Vous avez demandé le commentaire #793484.

telnet

Posté par Philippe Martin () le 12/01/2007 à 07:13. (lien). Évalué à 1.

Tu peux aussi regarder si le port 3306 de ton maître est accessible depuis l'escalve :

Depuis ta machine esclave :

telnet ip_maitre 3306

  • [^]Re: telnet

    Posté par morgane brocquevielle () le 12/01/2007 à 08:08. (lien). Évalué à 1.

    J'ai essayé telnet, de l'esclave vers le maitre, et il me met : "telnet : unable to connect to remote host : connection timed out".

    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 () le 12/01/2007 à 11:42. (lien). Évalué à 1.

      Morgane,

      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 () le 12/01/2007 à 13:24. (lien). Évalué à 1.

        J'ai déjà un test des ports via tcpdump en fait. Et ça m'a donné de drôle de résultat..

        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 () le 12/01/2007 à 23:24. (lien). Évalué à 1.

          Pourquoi (un tcpdump de) 192.168.1.2 ?

          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 () le 15/01/2007 à 10:52. (lien). Évalué à 1.

            Ah c'est une erreur de frappe...
            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...