Diagnosticando problemas de replicação do Mysql

Question

Temos um cliente de replicação mysql em execução no nosso servidor de backup. Desde uma falha de energia na semana passada, parou de se replicar. Antes disso, funcionava ininterruptamente durante vários meses.

Eu tentei reiniciar o mestre e o escravo, mas isso não ajudou. Eu posso acessar o servidor mestre 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

Update: Os erros estavam entrando no daemon.log, não no mysql.err, o que explicaria porque eu não consegui encontrá-los. O problema parece ser que o mestre está dizendo que o log está indisponível, o que não faz muito sentido, porque esse log (e o anterior) ainda estão disponíveis no mestre.

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

    

Answer 1

Bem-vindo ao maravilhoso mundo da replicação do MySQL. Eu mesmo não atingi o seu problema em particular, mas eu tenho encontrado muitos outros problemas estranhos e a solução imediata é apenas ressincronizar o mestre como se ele fosse um novo escravo e acabar com isso.

    

Answer 2

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

Você deve ter os logs de erro do mysql ligados ao seu sistema de monitoramento, caso contrário, seus escravos são potencialmente inúteis.

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

E para ser de alguma utilidade, você também vai querer verificar a sincronização dos escravos de vez em quando, talvez usando algo como mk-table-checksum; O ideal é amarrar os resultados disso em seu sistema de monitoramento também.

    

Answer 3

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

    

Answer 4

Como o womble mencionou, esqueça a solução de erros de replicação. A coisa que mais me preocupa sobre essa abordagem é que você pode ter sucesso em fazer a replicação reiniciar novamente e achar que tudo está bem, mas e se algumas partes do seu banco de dados ainda estiverem fora de sincronia?

O melhor é ativar o banco de dados escravo e reiniciar a replicação a partir de um instantâneo do mestre. Não deve ser tão perturbador quanto você pensa:

link

    

Answer 5

A partir do relatório acima eu encontrei o problema, este fidedigno deve ser definido para (Slave_IO_Running): sim, mas no relatório acima está mostrando Slave_IO_Running: Não.

Isso está causando o problema. Se essa variável for "Não", o segmento de E / S foi interrompido. então não há mais replicação. Você terá que verificar o Last_SQL_Errno e Last_SQL_Err para obter mais informações sobre a causa. Um número de erro de 0 e uma mensagem da string vazia significam "nenhum erro". O Last_SQL_Error aparece no log de erros do escravo.

Para corrigir esse problema, pare o escravo

Em seguida, defina:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Isto diz ao escravo para pular uma consulta (que é a inválida que causou a parada da replicação). Se você 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 registros, esperando que isso corrija o problema ...