Réplication MySQL: secondes derrière Master super haut

J'ai mis en place un serveur db esclave pour ma base de données de production, mais lorsque j'ai vérifié l'état de l'esclave, j'ai remarqué un très grand nombre en quelques secondes derrière master.

Voici la sortie:

           Slave_IO_State: Waiting for master to send event
              Master_Host: 1.2.3.4
              Master_User: replicator
              Master_Port: 3306
            Connect_Retry: 60
          Master_Log_File: mysql-bin.000173
      Read_Master_Log_Pos: 15909435
           Relay_Log_File: mysqld-relay-bin.000079
            Relay_Log_Pos: 91173356
    Relay_Master_Log_File: mysql-bin.000093
         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: 91173210
          Relay_Log_Space: 8179978166
          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: 486330
Master_SSL_Verify_Server_Cert: No
            Last_IO_Errno: 0
            Last_IO_Error: 
           Last_SQL_Errno: 0
           Last_SQL_Error: 
Replicate_Ignore_Server_Ids: 
         Master_Server_Id: 1
1 row in set (0.00 sec)

ERROR: 
No query specified

Ensuite, lorsque j'exécute SHOW PROCESSLIST, je vois que l'heure du thread correspond à l'heure indiquée en secondes derrière:

mysql> SHOW PROCESSLIST;

| 40 | system user |           | NULL | Connect |  66530 | Waiting for master to send event | NULL             |
| 41 | system user |           | NULL | Connect | 486330 | Reading event from the relay log | NULL             |
| 45 | root        | localhost | NULL | Query   |      0 | NULL                             | SHOW PROCESSLIST |

Ce temps baisse, lentement. Read_Master_Log_Pos, Relay_Log_Pos, Exec_Master_Log_Pos et Relay_Log_Space changent tout le temps.

J'ai également vérifié l'heure / la date et les deux serveurs sont synchronisés.

Côté Master:

mysql> SHOW PROCESSLIST;

| 66739 | replicator | 1.2.3.5:52884 | NULL                | Binlog Dump |    65671 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             

et montrer que les hôtes esclaves semblent vides ...

mysql> SHOW SLAVE HOSTS;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         2 |      | 3306 |         1 |
+-----------+------+------+-----------+
1 row in set (0.00 sec)

mysql> 

Alors que se passe-t-il réellement ici? On dirait que l'esclave est réellement connecté et fonctionne, mais très très lent? Quelqu'un peut-il me donner des conseils sur la façon de faire plus de débogage à ce sujet? Le serveur est plutôt inactif à 95%.

Lorsque vous voyez Seconds_Behind_Masterce haut, je regarde ce qui suit:

Relay_Log_Space: 8179978166

Vous avez 7,6182 Go de journaux de relais à traiter.

Master_Log_File: mysql-bin.000173
Relay_Master_Log_File: mysql-bin.000093

Cela me dit que vous avez lu jusqu'à mysql-bin.000173, mais vous traitez actuellement des choses à partir du mysql-bin.000093.

Cela me dit également que vous avez environ 80 journaux binaires sur le maître, chacun d'environ 100 Mo.

Il Seconds_Behind_Masters'agit simplement du NOW () moins le TIMESTAMP défini à la mysql-bin.000093position 91173210(Relay_Master_Log_File) (Exec_Master_Log_Pos).

Tant que Slave_SQL_Thread est Oui, les journaux de relais sont traités

• Relay_Log_Space diminue chaque fois qu'un journal de relais est effectué
• Exec_Master_Log_Pos augmentera jusqu'à ce que le journal de relais actuel soit terminé, puis réinitialise au début du relais suivant
• TIMESTAMP continue d'augmenter, ce qui Seconds_Behind_Masterdiminue (NOW () moins le TIMESTAMP défini à la position Relay_Master_Log_File Exec_Master_Log_Pos)

C'est ce qui se produit lorsque la réplication est désactivée pendant 486330 secondes (5 jours 15 heures 5 minutes 29 secondes) et que vous exécutez start slave;

Regardez votre SHOW PROCESSLIST;. Le fil d'E / S a été activé pendant 66530 secondes (18 heures 28 minutes 50 secondes). Cela signifie que quelqu'un ou quelque chose a commencé la réplication il y a 18 heures 28 minutes 50 secondes.

Vous avez indiqué dans votre question que vous avez configuré la réplication pour le serveur de production. Cela signifie que vous avez exécuté mysqldump il y a 5 jours 15 heures 5 minutes 29 secondes et que vous avez commencé à répliquer à partir du maître de production il y a 18 heures 28 minutes 50 secondes.

Si vous aviez configuré l'esclave le même jour que vous avez obtenu le mysqldump du maître, la charge de réplication serait bien moindre. Nonobstant, la réplication fonctionne normalement, Slave_IO_Threadet les Slave_SQL_Threaddeux disent Yes.