故障分析 | 手动 rm 掉 binlog 导致主从报错

故障分析 | 手动 rm 掉 binlog 导致主从报错

故障描述：客户反馈复制报错 1236，报错提示为从库读取到主库不存在的 binlog 日志，导致复制中断。报错截图显示为 'Could not open log file'。数据库版本为 5.7.31，GTID 启用。

故障分析：首先，登录从库查看报错信息，发现 io 线程断了，并报错 'Got fatal error 1236 from master when reading data from binary log: 'Could not open log file'。从库的 error 日志报错指出无法从主库获取 binlog 日志，GTID 停止在 828415。进一步查看主库的 binlog 和 error 日志，发现主库 binlog 日志连续，但 mysql-bin.index 文件记录了两个 mysql-bin.000006 文件，而实际只有一个。

继续查看主库 binlog 的解析，发现 mysql-bin.000005 的最后一个事务 GTID 为 'c582a82e-b985-11ec-adf5-02000aba3e89:828415'，与从库停止 GTID 的位置一致。mysql-bin.000006 的第一个事务 GTID 为 'c582a82e-b985-11ec-adf5-02000aba3e89:855706'，与前一个 binlog.000005 有两万多个 GTID 事务的差异，说明确实存在事务丢失。问题出在 mysql-bin.000006 这个 binlog 日志上，但主库 binlog 日志有此文件，需分析此情况。

通过复现，发现主库在复制状态正常时，手动删除当前正在使用的 binlog 日志后，刷新日志，binlog 会重新生成被删除的文件，此时 binlog 日志连续，但 mysql-bin.index 文件记录着两个相同的文件名。这与客户场景一致。测试结果表明，当正在使用 binlog 文件被手动删除时，binlog 文件计数器不受影响，刷新后会根据当前最大 binlog 文件+1生成新的文件，导致 index 文件记录重复。客户复制故障场景可通过复现，首先主从有一定延迟，从库获取主库 binlog.000006，删除主库当前使用 binlog.000007，从库在读取完 binlog.000006 后尝试获取 binlog.000007，但由于文件已被删除，导致复制报错。

建议：人为删除正在使用的 binlog 文件基本会导致主从报错或主从不一致。在出现这种情况时，除了重做从库外，一般没有较好的解决方法，这不利于数据库维护。建议避免手动删除正在使用的 binlog 文件，并采取措施监控和预防这种情况发生，如定期备份和检查 binlog 状态，以确保数据库的稳定性和一致性。2024-11-10