Réplication mysql réussie mais l'esclave ne se réplique pas

J'ai créé une configuration maître-esclave mysql et les choses vont bien. le "afficher l'état du maître;" sur l'esclave ne montre aucune erreur. c'est la sortie

 Slave_IO_State: Waiting for master to send event
                  Master_Host: 109.123.100.58
                  Master_User: replica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 106
               Relay_Log_File: relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 106
              Relay_Log_Space: 106
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 

Cependant, la réplication sur l'esclave ne semble pas se produire lorsque le maître subit un changement

Sur maître. AFFICHER LE STATUT DE MAÎTRE

+------------------+----------+--------------+-------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB        |
+------------------+----------+--------------+-------------------------+
| mysql-bin.000001 |   639495 |              | mysql,informationschema |
+------------------+----------+--------------+-------------------------+

sur l'esclave SHOW PROCESSLIST donne

+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
| Id  | User        | Host      | db   | Command | Time  | State                                                                 | Info             |
+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
| 174 | system user |           | NULL | Connect | 25777 | Waiting for master to send event                                      | NULL             |
| 175 | system user |           | NULL | Connect | 25777 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 199 | root        | localhost | NULL | Query   |     0 | NULL                                                                  | show processlist |
+-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

Suis-je en train de manquer quelque chose

Le résultat que vous avez présenté est très déroutant. D'une part, le maître montre:

mysql-bin.000001   639495 

L'esclave PROCESSLISTindique que la réplication fonctionne (le thread IO est connecté au maître, le thread SQL attend).

L'esclave SHOW SLAVE STATUSprétend à nouveau que tout va bien, mais la position du maître l'est 106.

Toutes ces sorties sont-elles publiées à peu près en même temps? Sinon, ils n'ont pas de valeur.

Je vérifierais les points suivants:

• L'évidence: c'est 109.123.100.58vraiment votre maître?
• Le SHOW PROCESSLISTmaître répertorie-t-il la connexion établie par l'esclave sous l' replicautilisateur?
• Avez-vous différents server-idréglages pour maître et esclave?
• Avez-vous des paramètres replicate-do-*ou replicate-ignore-*dans votre mysql.cnffichier?

Mieux que d'utiliser binlog-ignore-db est d'utiliser le filtrage côté esclave. J'étais coincé dans une situation similaire, oui, il m'a fallu une journée entière pour comprendre:

J'ai raté quelque chose de grand !!!

La différence entre

--replicate-do-db=
--replicate-do-table=

Du côté des esclaves. Et

--replicate-do-table='mydb.%'

n'a pas fonctionné pour moi sur -do-table. Je devais utiliser

--replicate-do-db='mydb'

Je suppose que cela aurait fonctionné pour un caractère générique

--replicate-wild-do-table='mydb.%'

... Maintenant, découvrez comment répliquer la même table à partir de plusieurs maîtres. D'accord, je l'ai compris, MySQL ne le supporte pas nativement; MariaDB 10 le fait.

J'ai également eu un autre problème au départ: mon mot de passe dépassait 32 caractères. Huer!

J'ai également rencontré ce problème. La cause profonde était d'avoir le maître server_id=0. MariaDB a un comportement spécial pour server_id=0lequel la réplication ne fonctionnera pas.

Le server_id doit être unique pour chaque serveur du groupe de réplication. S'il est laissé à 0, la valeur par défaut jusqu'à MariaDB 10.2.1, un esclave ne se connectera pas à un maître et un maître refusera toutes les connexions esclaves.

Quand j'ai commencé l'indexation basée sur 1, tout fonctionnait bien.

Vous n'avez pas indiqué à l'esclave la base de données à répliquer: la variable Replicate_Do_DB est vide.

Essayez d'ajouter la ligne

replicate-do-db = nom_de_db (où "nom_de_db" est le nom de la base de données à répliquer)

dans votre my.cnf (sur esclave) et redémarrez le serveur esclave.

EDIT: Je ne pense pas que ma réponse soit la bonne solution, en attendant ;-)

Peut-être jetez un œil à cette page à la place: http://dev.mysql.com/doc/refman/5.1/en/replication-problems.html