主页 / dba / 问题 / 20272
Accepted
Dave Rix
Asked: 2012-07-03 08:06:41 +0800 CST

使用 mysqlbinlog 读取 MySQL 5.5 二进制日志时出错

  • 772

我正在使用的复制设置遇到问题。它已经工作了好几个月了，然后在周末，slave 停止从 master 的 binlog 读取更新并出现错误Got fatal error 1236 from master when reading data from binary log: 'bogus data in log event'

尝试使用 mysqlbinlog 读取相关的二进制日志时，出现如下所示的错误；

[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] #

令人沮丧！--start-position我曾尝试使用和的各种组合--offset来尝试克服不良数据，但似乎没有任何效果......

我所追求的是一种从二进制日志中跳过（或删除）此错误的方法，创建一个没有违规项目的新二进制日志，以便我可以继续我的复制。

我不担心丢失声明，这是一个 syslog 收集数据库，丢失一行不会受到伤害。

我不能做的是从主人重新创建奴隶，因为主人使用BLACKHOLE引擎，因此没有存储真实数据......

如果最坏的情况发生在最坏的情况下，我将不得不从序列中的下一个二进制日志开始，并松散留在有问题的日志中的数据。

在此先感谢，戴夫

mysql replication

2 个回答

  1. Best Answer

    由于 Master 上的二进制日志已损坏，因此您无能为力。节哀顺变。直接跳到下一个 binlog：

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

    当然，107 是 MySQL 5.5 binlogs 的起始位置。如果 Master 是 5.1（或 5.0.95），使用 106。如果 Master 在 5.1 之前，使用 98。

    如果 Master BinLog Corruption 频繁，可能需要考虑在 Master 上使用更小的二进制日志（可能是 128M 而不是默认的 1G）：

    [mysqld]
max_binlog_size=128M

    这不会阻止损坏，但降低它的大小会将数据丢失从 1G 降至 128M。

    • 2

  2. 我曾经有一个非常相似的问题。

    正如您已经提到的，问题是要找到正确的 --start-position。

    我通过使用 hexeditor / xxd 查看损坏的二进制日志文件解决了这个问题（在我的情况下，找到一些在损坏位置归零的块），通过查找下一部分来跳过二进制日志文件的这个明显损坏的部分，其中一些有用的 SQL 语句在 hexdump 中可见，并且 binlog 可能再次完好无损。

    为了在 Hexdump 中识别正确的 binlog-header，我查看了http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log上的开发人员文档。

    基本上，标头以时间戳（4 字节）、类型归档（1 字节）和主服务器复制 ID（4 字节）开始。

    在我的情况下，Server-ID 相对容易识别，所以我从我认为是 Server-ID 的位置中减去 5，并将这个值作为 start-position 输入到 mysqlbinlog - 它很高兴。

    将其设置为从属上的新主位置最终使复制再次运行。

    是的，这是“肮脏的”，您会丢失一些陈述，但是您已经意识到这一点，也许这对您的情况有所帮助。

    • 1

相关问题