Replicação MySQL: Segundos atrás do mestre super alto


8

Eu configurei um servidor slave db para o meu banco de dados de produção, mas quando verifiquei o status show slave, notei um número super grande em segundos atrás do master.

Esta é a saída:

           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

Então, quando executo o SHOW PROCESSLIST, vejo que o tempo do thread corresponde ao tempo indicado em segundos:

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 |

Esse tempo está caindo lentamente. Read_Master_Log_Pos, Relay_Log_Pos, Exec_Master_Log_Pos e Relay_Log_Space estão mudando o tempo todo.

Também verifiquei a hora / data e os dois servidores estão sincronizados.

No lado mestre:

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             

e mostrar hosts escravos parece vazio ...

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

mysql> 

Então, o que realmente está acontecendo aqui? Parece que o escravo está realmente conectado e funcionando, mas muito, muito devagar? Alguém pode me dar algumas dicas sobre como fazer mais depuração nisso? O servidor está inativo em 95%.

Respostas:


15

Quando você vê Seconds_Behind_Masteresse ponto alto, olho para o seguinte:

Relay_Log_Space: 8179978166

Você possui 7,6182 GB de logs de retransmissão para processar.

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

Isso me diz que você leu mysql-bin.000173, mas atualmente está processando as coisas no mysql-bin.000093.

Isso também me diz que você tem cerca de 80 logs binários no Master, cada um com cerca de 100 MB.

O Seconds_Behind_Masteré simplesmente o NOW () menos o conjunto de carimbo do tempo no mysql-bin.000093(Relay_Master_Log_File) posição 91173210(Exec_Master_Log_Pos).

Enquanto Slave_SQL_Thread for Sim, os logs de retransmissão serão processados

  • Relay_Log_Space diminuirá sempre que um log de retransmissão for concluído
  • Exec_Master_Log_Pos aumentará até que o registro atual do relé seja concluído e redefinido para o início do próximo relé
  • TIMESTAMP continua aumentando, o que Seconds_Behind_Masterdiminui (NOW () menos o TIMESTAMP definido na posição Relay_Master_Log_File Exec_Master_Log_Pos)

É o que acontece quando a replicação está desativada por 486330 segundos (5 dias 15 horas 5 minutos 29 segundos) e você executa start slave;

Olhe para o seu SHOW PROCESSLIST;. O encadeamento IO permanece ativo por 66530 segundos (18 horas 28 minutos e 50 segundos). Isso significa que alguém ou algo iniciou a replicação há 18 horas e 28 minutos e 50 segundos atrás.

Você declarou em sua pergunta que configurou a replicação para o servidor de produção. Isso significa que você executou o mysqldump 5 dias 15 horas 5 minutos 29 segundos atrás e começou a replicar a partir do mestre de produção 18 horas 28 minutos 50 segundos atrás.

Se você tivesse configurado o Escravo no mesmo dia em que obteve o mysqldump do Master, a carga de replicação seria muito menor. Não obstante, a replicação está funcionando normalmente, Slave_IO_Threade Slave_SQL_Threadambos dizem Yes.


11
Corrigir. O SLAVE START estava programado para ser executado um dia após o despejo MASTER, mas isso não aconteceu, então tive que SLAVE START após um longo fim de semana. O que eu fiz foi definir innodb_flush_log_at_trx_commit = 2 e isso reduziu o LAG. Quão seguro é fazer isso?
Matías
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.