☰

Diagnosticando problemas de replicação do MySQL

tag-icon • tag-icon mysql mysql-replication
Diagnosticando problemas de replicação do MySQL

Temos um cliente de replicação mysql em execução em nosso servidor de backup. Desde uma falha de energia na semana passada, a replicação parou. Antes disso, ele funcionou ininterruptamente por vários meses.

Tentei reiniciar o mestre e o escravo, mas isso não ajudou. Posso acessar o servidor mestre a partir do escravo, então a rede não é o problema.

Há mais alguma coisa que eu possa fazer para tentar diagnosticar qual é o problema?

mysql> show slave status\G;
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: master
                Master_User: username
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000060
        Read_Master_Log_Pos: 46277494
             Relay_Log_File: mysqld-relay-bin.000348
              Relay_Log_Pos: 98
      Relay_Master_Log_File: mysql-bin.000060
           Slave_IO_Running: No
          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: 46277494
            Relay_Log_Space: 98
            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: NULL
1 row in set (0.00 sec)

ERROR:
No query specified


mysql> show master status\G;
*************************** 1. row ***************************
            File: mysql-bin.000069
        Position: 851796
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

ERROR:
No query specified

Atualização: os erros estavam indo para daemon.log, não para mysql.err, o que explicaria por que não consegui encontrá-los. O problema parece ser que o master está dizendo que o log está indisponível, o que não faz muito sentido, pois esse log (e o anterior) ainda estão disponíveis no master.

090710  9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98
090710  9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306',  replication started in log 'mysql-bin.000060' at position 46277494
090710  9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090710  9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090710  9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494

Responder1

Bem-vindo ao maravilhoso mundo da replicação MySQL. Eu não abordei seu problema específico, mas encontrei muitos outros problemas estranhos e a solução imediata é apenas ressincronizar do mestre como se fosse um escravo totalmente novo e pronto.

Responder2

Você deve examinar o log de erros do escravo - geralmente é bastante explícito sobre qual é o problema.

Você deve ter os logs de erros do MySQL vinculados ao seu sistema de monitoramento, caso contrário, seus escravos serão potencialmente inúteis.

Além disso, você deve ter um monitor que verifique o status do escravo.

E para ter alguma utilidade, você também vai querer verificar a sincronização dos escravos de tempos em tempos, talvez usando algo como mk-table-checksum; idealmente, vincule os resultados disso também ao seu sistema de monitoramento.

Responder3

Muitas pessoas configuram skip-slave-start para que possam ter certeza de que tudo está bem se um escravo parar de replicar antes de iniciá-lo. Tente executar 'start slave' e veja se algo muda ou se algo é registrado. Além disso, é estranho que o processo SlaveSQL esteja em execução e o SlaveIO não. É possível que os logs de retransmissão locais no escravo tenham sido corrompidos, embora issodeveser relatado nos logs. Você pode tentar desativar o Mysql e excluir os logs de retransmissão.

Responder4

No relatório acima, encontrei o problema, este campo deve ser definido como (Slave_IO_Running): sim, mas no relatório acima está mostrando Slave_IO_Running: No.

Isso está causando o problema. Se esta variável for 'Não', o encadeamento IO foi interrompido. então não há mais replicação. Você terá que verificar Last_SQL_Errno e Last_SQL_Err para obter mais informações sobre a causa. Um número de erro 0 e uma mensagem de string vazia significam “sem erro”. O Last_SQL_Error aparece no log de erros do escravo.

Para corrigir esse problema, pare o escravo

Então defina:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Isso diz ao escravo para pular uma consulta (que é a inválida que causou a parada da replicação). Se quiser pular duas consultas, você usaria SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; em vez disso e assim por diante.

Em seguida, reinicie o escravo e verifique os logs, esperando que isso resolva o problema...

informação relacionada