为什么开启binlog_checksum会导致MySQL复制中断？-mysql教程-PHP中文网

MySQL主从复制中Binlog校验和导致解析失败的根源是主从checksum算法不一致或relay log损坏，SQL线程因校验失败报错退出；修复需停复制、RESET SLAVE ALL清空relay log、重启mysqld（依赖relay_log_recovery=ON自动重建），或手动CHANGE MASTER TO重设位点。

为什么开启binlog_checksum会导致mysql复制中断？

开启 binlog_checksum 本身不会导致复制中断，但**主从库 checksum 算法不一致或从库 relay log 损坏时，SQL 线程会因校验失败直接报错退出**——这是最常见的“开启后复制中断”表象。

为什么 binlog_checksum=ON 会让 SQL 线程卡住？

MySQL 5.6+ 默认启用 binlog_checksum=CRC32，主库写 binlog 时会在每个 event 末尾追加校验值。从库 IO 线程拉取后存入 relay log，SQL 线程回放前会重新计算并比对。一旦不匹配，就拒绝执行并报错：

Got fatal error 1236 from master when reading data from binary log: 'binlog event entry corrupted'

常见触发场景：

主库用 CRC32，从库 my.cnf 中显式设了 binlog_checksum=NONE（或 MySQL 5.5/5.6 旧版本未支持该参数）
relay log 文件在磁盘损坏、异常断电或被手动截断后，checksum 字段被破坏
主从 MySQL 版本差异较大（如主库 8.0.33，从库 5.7.40），CRC32 实现细节有微小偏差（极少见，但非零概率）

如何快速确认是不是 checksum 校验问题？

登录从库执行 SHOW SLAVE STATUS\G，重点看三处：

— Last_IO_Errno 和 Last_IO_Error：如果是 IO 层校验失败，这里会直接提示 “checksum mismatch” 或 “invalid event length”

— Last_SQL_Errno 和 Last_SQL_Error：如果 IO 成功但 SQL 回放失败，错误信息里含 “corrupted”、“checksum”、“event entry” 关键词，基本可锁定

— 对比主从 SELECT @@binlog_checksum;：必须完全一致（大小写敏感，CRC32 ≠ crc32）

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

修复 relay log checksum 失败的实操步骤

注意：这不是调参数就能绕过的逻辑层校验，而是数据完整性保护机制。跳过 checksum 检查（如临时设 binlog_checksum=NONE）风险极高，**不推荐**。

正确做法是重建 relay log，前提是已启用 relay_log_recovery=ON（MySQL 5.7+ 默认 OFF，必须显式配置）：

停复制：STOP SLAVE;
清空 relay log：RESET SLAVE ALL;（删除 relay-log.index 和所有 relay-log.* 文件）
重启 mysqld 进程（关键！只有重启时 relay_log_recovery=ON 才会触发自动重拉缺失 binlog 并重建 relay log）
启动复制：START SLAVE;

若无法重启 mysqld，且你已确认主库当前 SHOW MASTER STATUS 的 File 和 Position，可用 CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy; 手动指定起点后 START SLAVE —— 但前提是主库 binlog 未被 expire_logs_days 清理。