寻找一种有效的方法来解决“无法解析中继日志事件条目...”错误

Question

我在 MySQL 5.0 中有一个损坏的中继日志，正在寻找修复复制的步骤，而不必再次重新处理来自主服务器的所有二进制日志。

如果您好奇，这里是完整的错误消息：
无法解析中继日志事件条目。可能的原因有：master的二进制日志损坏（可以通过运行'mysqlbinlog'查看二进制日志），slave的relay log损坏（可以通过运行'mysqlbinlog'查看relay log），a网络问题，或者 master 或 slave 的 MySQL 代码中的错误。如果您想检查主站的二进制日志或从站的中继日志，您将能够通过在此从站上发出“显示从站状态”来知道它们的名称。

正常的修复非常简单，您只需从 show slave status 中获取正确的二进制日志名称和位置并运行 change master 命令。但这不是我想做的。

我只想重新处理来自 master 的一个或几个二进制日志以恢复损坏的中继日志，然后继续使用已经创建的中继日志。我正在寻找过去有这样做经验的人，因为以这种方式进行恢复可能会失败。

从概念上讲，我认为可能需要以下步骤（也许其中一些是可选的）：

1. 停止从服务器上的复制。
2. 关闭从属实例。
3. 将中继日志移动到安全位置。
4. 查看是否需要手动更新relay-log.info 或master.info 文件。
5. 启动从属实例。
6. 运行 change master 命令并从失败的位置重新处理二进制日志。
7. 等待直到创建下一个中继日志。
8. 停止从服务器上的复制。
9. 关闭从属实例。
10. 弄清楚如何用位于安全位置的中继日志文件替换第二个中继日志文件并将它们移入。
11. 查看是否需要手动更新relay-log.info 或master.info 文件。
12. 启动从属实例。
13. 希望最好的。

我正在考虑另一种方法来做到这一点，这似乎更简单：

1. 停止从服务器上的复制。
2. 关闭从属实例。
3. 将中继日志移动到安全位置。
4. 启动从属实例。
5. 运行 change master 命令并从失败的位置重新处理二进制日志。
6. 等待直到创建下一个中继日志。
7. 停止从服务器上的复制。
8. 使用 mysqlbinlog 通过管道传输到 mysql 客户端来处理位于安全位置的中继日志。确定从哪个文件和位置开始。（潜在的问题，除非在第一次错误时中止处理）。
9. 将从服务器设置为在读取的主日志文件/位置从主服务器复制。

Answer 1

您可以尝试更稳定的方法

这里有一些事情要记住

无论何时运行CHANGE MASTER TO，它都会清除您拥有的每个中继日志。您不想保留尚未执行任何 SQL 的命令的中继日志

以下是我在 2012 年 2 月 3 日发表的一篇文章的摘录：How to resolve the master server shutdown/unavailable in mysql with master-slave replication：

请注意，Master 有两组复制坐标

• (Master_Log_File,Read_Master_Log_Pos)
• (Relay_Master_Log_File,Exec_Master_Log_Pos)

它们之间有很大的区别

• (Master_Log_File,Read_Master_Log_Pos) 告诉您 Master 日志文件中的最后一个 binlog 语句和 Slave 从 Master 读取并放置在其中继日志中的日志位置。
• (Relay_Master_Log_File,Exec_Master_Log_Pos)告诉你来自 Master 的日志文件和日志位置的最后一个 binlog 语句，Slave 从 Master 读取并放置在它的 Relay Logs 中，THAT IS NEXT TO BE EXECUTED ON THE SLAVE。

你想要的是两件事：

1. 擦除您拥有的每个二进制日志
2. 开始从您成功执行的最后一条 SQL 中收集二进制日志条目。

在您的情况下，您必须使用第二组复制坐标

• Relay_Master_Log_File
• Exec_Master_Log_Pos

如错误消息所示，很容易不信任损坏的中继日志。伤害最大的是损坏的主日志。如果是这种情况，您将不得不跳过箍。另一方面，如果其他情况之一是导致中继日志损坏的原因，那么最简单、最简洁的方法就是我所说的。

为了确保无论报告为Relay_Master_Log_File，如果该特定二进制日志仍然存在于主服务器上，请对其执行 mysqlbinlog。如果它完全转储而没有损坏的字符，请继续使用第二组复制坐标。

来自我之前的帖子

mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.48.20.253
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000254
        Read_Master_Log_Pos: 858190247
             Relay_Log_File: relay-bin.066069
              Relay_Log_Pos: 873918
      Relay_Master_Log_File: mysql-bin.000254
           Slave_IO_Running: Yes
          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: 858190247
            Relay_Log_Space: 873772
            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: 0
1 row in set (0.00 sec)

请注意，SHOW SLAVE STATUS\G上次执行的复制坐标是(mysql-bin.000254,858190247). CHANGE MASTER TO在这种情况下，命令是：

CHANGE MASTER TO master_log_file='mysql-bin.000254',master_log_pos=858190247;

试一试 ！！！

更新 2012-09-14 16:38 EDT

如果您担心存储中继日志，只需限制中继日志即可。在 中SHOW SLAVE STATUS\G，有一个名为 的字段Relay_Log_Space。这为您提供了所有中继大小的总和（以字节为单位）。你知道你可以限制这个数字吗？

该选项称为relay_log_space_limit。

例如，如果要将总字节数限制为 10G，请执行以下操作

STEP 01) 将此添加到 Slave 上的 /etc/my.cnf

[mysqld]
relay_log_space_limit = 10G

STEP 02)service mysql restart在从站上运行

就是这样！！！

当最旧的中继处理完其所有条目后，它将被删除并创建新的中继日志。在所有中继日志加起来为 10G 之前，它会被填满。这是控制失控中继日志空间问题的唯一方法。

更新 2012-09-14 18:10 EDT

建议：如果您在每半夜对 Slave 上的数据进行 mysqldump 备份，您可以设置以下内容以限制 1TB 的二进制日志：

STEP 01) 将此添加到 Master 上的 /etc/my.cnf

[mysqld]
expire_logs_days = 14

STEP 02) 在 Master 上运行这个查询

mysql> PURGE BINARY LOGS BEFORE DATE(NOW()) - INTERVAL 14 DAY;

STEP 03)service mysql restart在主控器上

STEP 04) 在 Slave 上的 crontab 中添加一个 mysqldump 备份脚本

这将使 Slave 更有用，并且可以控制多余的二进制日志来担心