MySQL主从复制中Binlog校验和导致解析失败的根源是主从checksum算法不一致或relay log损坏，SQL线程因校验失败报错退出；修复需停复制、RESET SLAVE ALL清空relay log、重启mysqld（依赖relay_log_recovery=ON自动重建），或手动CHANGE MASTER TO重设位点。
开启 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）
修复 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 清理。
最容易被忽略的兼容性细节
checksum 不只是开关问题，它和 binlog 格式、GTID、甚至半同步都存在隐式耦合：
— binlog_format=ROW 下 event 更大，checksum 错误更容易暴露 relay log 存储层问题（如文件系统只写入部分 event）
— GTID 模式下，Retrieved_Gtid_Set 和 Executed_Gtid_Set 差集可能掩盖 checksum 失败的真实位置，需结合 Relay_Master_Log_File + Exec_Master_Log_Pos 定位具体事件
— 半同步复制中，若主库等待 ACK 时发生 checksum 校验失败，从库 SQL 线程已退出，但主库仍认为事务已安全落盘，此时数据一致性需人工介入验证
