Início / dba / Perguntas / 20272
Accepted
Dave Rix
Asked: 2012-07-03 08:06:41 +0800 CST

Erro ao ler o log binário do MySQL 5.5 usando mysqlbinlog

  • 772

Estou tendo alguns problemas com uma configuração de replicação que estou usando. Está funcionando bem há meses e, no fim de semana, o escravo parou de ler as atualizações do log binário do mestre com um erroGot fatal error 1236 from master when reading data from binary log: 'bogus data in log event'

Ao tentar ler o log binário relevante usando mysqlbinlog, recebo o erro mostrado abaixo;

[root@slglcd-01] # mysqlbinlog ibm-pr-slglcd-01.000075 > /dev/null
ERROR: Error in Log_event::read_log_event(): 'Event too small', data_len: 0, event_type: 0
ERROR: Could not read entry at offset 1828: Error in log format or read error.
[root@slglcd-01] #

Frustrante! Eu tentei usar várias combinações de --start-positione --offsetpara tentar superar os dados ruins, e nada parece estar funcionando...

O que estou procurando é uma maneira de pular (ou remover) esse erro de dentro do log binário, criando um novo log binário sem o item ofensivo, para que eu possa continuar minha replicação.

Não estou preocupado em perder a instrução, este é um banco de dados de coleção de syslog e uma linha ausente não vai doer.

O que não posso fazer é recriar o escravo a partir do mestre, pois o mestre usa o BLACKHOLEmecanismo e, portanto, não possui dados reais armazenados ...

Se o pior acontecer, terei que começar a partir do próximo log binário na sequência e perder os dados deixados no log ofensivo.

Desde já obrigado Dave

mysql replication

2 respostas

  1. Best Answer

    Como o log binário no mestre está corrompido, não há mais nada que você possa fazer. Minhas condolencias. Basta pular para o próximo binlog:

    STOP SLAVE;
CHANGE MASTER TO master_log_file='ibm-pr-slglcd-01.000076',master_log_pos=107;
START SLAVE;

    Obviamente, 107 é a posição inicial dos binlogs do MySQL 5.5. Se o Master for 5.1 (ou 5.0.95), use 106. Se o Master for anterior a 5.1, use 98.

    Se a corrupção do Master BinLog for frequente, você pode precisar considerar o uso de um tamanho menor para os logs binários no Master (talvez 128M em vez do 1G padrão):

    [mysqld]
max_binlog_size=128M

    Isso não impedirá a corrupção, mas diminuir o tamanho minimizará a perda de dados de 1G para 128M.

    • 2

  2. Eu tive um problema muito semelhante uma vez.

    Como você já mencionou, o problema é encontrar uma --start-position correta.

    Eu resolvi isso olhando para o arquivo binlog corrompido com um hexeditor / xxd (para encontrar alguns blocos zerados na posição corrompida no meu caso), pulando esta parte obviamente quebrada do arquivo binlog procurando a próxima parte onde alguns A instrução SQL útil estava visível no hexdump e o log binário estava possivelmente intacto novamente.

    Para identificar um cabeçalho binlog correto no Hexdump, examinei os documentos do desenvolvedor em http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log .

    Basicamente, um cabeçalho começa com um registro de data e hora (4 bytes), um arquivo de tipo (1 byte) e o Master-Server-Replication-ID (4 bytes).

    O ID do servidor foi relativamente fácil de identificar no meu caso, então subtraí 5 do que pensei ser a posição do ID do servidor e inseri esse valor como posição inicial para mysqlbinlog - e foi feliz.

    Definir isso como novo mestre-pos no escravo finalmente fez com que a replicação fosse executada novamente.

    Sim, isso é "sujo" e você perde algumas declarações, mas como você já sabe disso, talvez isso ajude no seu caso.

    • 1

relate perguntas