Por que a replicação do MySQL quebra na linha perdida e depois continua após “START SLAVE”?

Question

O título é um pouco confuso, mas não consigo pensar em um melhor.

O que eu tenho é uma replicação simples do MySQL, com o escravo ocasionalmente falhando, com este erro: Error 'Can't find record in 'my_tbl'' on query. Default database: 'my_db'. Query: 'UPDATE my_tbl SET ... WHERE ...' (colunas omitidas para maior clareza).

O que eu estou supondo que este erro significa, é que o thread sql slave executou esta atualização e recebeu 0 rows affected . Isso não era o que esperava ao comparar o resultado de 1 rows affected do relay log, gerando um erro.

Ao executar essa mesma transação de atualização manualmente, ela funciona. A mesma coisa ao executar START SLAVE - ele apenas começa a funcionar e volta ao normal.

Isso não faz sentido para mim - se tudo o que é preciso é uma "nova tentativa" para consertar isso, como isso pode acontecer em primeiro lugar? Tudo é executado de forma serializada, e nada mais está gravando no servidor mysql slave.

Alguém pode fornecer uma explicação?

Alguns detalhes técnicos - esta é uma configuração de replicação mista de 5.5.7-rc a 5.5.12.

    

Answer 1

Existe um bug do MySQL # 60091 sobre a replicação de tabelas InnoDB que podem atender às suas condições - dê uma olhada, verifique se sua versão foi afetada e atualize-a, eventualmente, para verificar se isso ajuda.

Outra explicação para isso seria a execução fora de ordem - quando o UPDATE my_tbl SET ... WHERE ... é executado, a condição WHERE ainda não pode ser atendida por nenhuma linha, uma vez que ainda precisa acontecer. Eu não consigo pensar em uma razão para isso - isso seria algo sobre as listas de discussão do MySQL.

    

Answer 2

Eu descobri o motivo por trás desse problema - um evento que estava sendo executado no mestre e no escravo também. A solução é simples - alter event event_name disable on slave; Algo que você deve ter em mente ao criar um escravo com mysqldump .