binlog_checksum 是 mysql 5.6.2+ 默认启用的 binlog 校验机制，主库写入时附加 crc32 校验和，从库解析 relay log 前校验，不匹配则报错 1236 中断同步，防止脏数据传播；必须开启，不可关闭。
binlog_checksum 是什么，为什么必须开
它不是可有可无的开关，而是 MySQL 5.6.2+ 默认启用、用于校验 binlog 事件完整性的机制。主库写入 binlog 时会附加 CRC32 校验和，从库在读取并解析 relay log 前会校验这个值——不匹配直接报错 Got fatal error 1236，中断同步，避免脏数据继续传播。
不开的话，网络抖动、磁盘静默错误、内存位翻转都可能让 binlog 片段损坏却无人察觉，从库默默执行错误 SQL，主从数据差异就此埋下。
如何确认和开启 binlog_checksum
检查当前状态：
SHOW VARIABLES LIKE 'binlog_checksum';返回
OFF 就得立刻处理。
- 动态开启（仅对后续新生成的 binlog 生效）：
SET GLOBAL binlog_checksum = 'CRC32';
- 永久生效：在主库
my.cnf的[mysqld]段落添加binlog_checksum = CRC32，重启 MySQL - 注意：从库不需要（也不应该）设置该参数；它只影响主库写 binlog 的行为
- MySQL 8.0.20+ 已移除
OFF选项，强制为CRC32，旧版本务必手动确认
开启后从库报错 ERROR 1236 的常见原因
这不是配置失败，恰恰说明校验机制起作用了——它拦下了已损坏的 binlog 流。典型触发场景：
- 主库在
binlog_checksum = OFF时期生成的旧 binlog 文件，被开启校验后的从库尝试读取（校验字段缺失或为 0） - 主库磁盘写入异常，导致某条 binlog event 的末尾校验和字段被截断或覆盖
- 使用了非官方复制工具（如某些自研中间件）未正确处理 checksum 字段，中转时丢弃或篡改
- 主从 MySQL 版本差异过大，低版本从库无法识别高版本新增的 checksum 结构（少见但存在）
修复动作不是关掉校验，而是重置复制位置到一个干净的 binlog 点，或重新搭建从库。
checksum 对性能和兼容性的影响很小，但别用错地方
CRC32 计算开销极低，实测对主库 TPS 影响通常低于 1%，远小于网络延迟或磁盘 I/O 的波动。真正要注意的是边界情况：
- 不要在从库上执行
SET GLOBAL binlog_checksum = ...—— 从库不写 binlog，该变量无效且可能干扰内部状态 - GTID 模式下，
binlog_checksum必须开启，否则CHANGE MASTER TO可能拒绝 GTID 自动定位 - 使用 mysqlbinlog 工具解析远程 binlog 时，需加
--base64-output=DECODE-ROWS --verbose，否则 checksum 字段可能干扰解析逻辑
最常被忽略的一点：主库开启了，但备份恢复时用了旧的 binlog 文件（比如 xtrabackup 备份包含关闭 checksum 时期产生的 binlog），从库拉取这些文件就会立即报错——这种“历史遗留 binlog”需要人工清理或跳过。
