binlog_checksum 是 MySQL 5.6.2+ 引入的 binlog 校验机制，默认 CRC32，用于主从复制中验证 binlog 事件完整性，防止因传输或存储损坏导致主从不一致；从库通过 slave_sql_verify_checksum 开启校验，不匹配则报错中断。
binlog_checksum 是什么，为什么主从复制需要它
binlog_checksum 是 MySQL 5.6.2+ 引入的配置项，用于在写入 binlog 时附加校验和（默认是 CRC32）。它的核心作用是：让从库在读取主库的 binlog 事件时，能验证数据在网络传输或磁盘读取过程中是否被意外篡改或损坏。
没有校验时，如果 binlog 文件因磁盘静默错误、网络丢包、IO 中断等原因导致某段 event 数据错位或截断，从库可能悄无声息地执行错误 SQL，造成主从数据不一致——这种问题极难定位。
开启 CRC32 校验的实际效果与行为变化
当 binlog_checksum = CRC32（MySQL 5.6.2+ 默认值），每个 binlog event 的末尾会多出 4 字节的校验字段。主库写入时计算并追加；从库 I/O 线程拉取后、SQL 线程执行前，会重新计算并比对——不匹配则报错中断，例如：
Got fatal error 1236 from master when reading data from binary log: 'checksum mismatch at XXXX; the first event 'mysql-bin.000001' at XXXX, the last event read from './mysql-bin.000001' at XXXX.'
- 主库必须开启
binlog_checksum = CRC32（或NONE），不能设为OFF（已废弃） - 从库的
slave_sql_verify_checksum = ON（MySQL 5.6.2+ 默认开启）才会在校验失败时中止 SQL 线程 - 若主库用
NONE，从库即使设了CRC32也无法校验（因为 binlog 里压根没 checksum 字段） - 启用后 binlog 文件体积略微增大（每 event +4 字节），但对性能影响可忽略
常见误配场景和排障要点
主从校验失败不一定是数据损坏，更常源于配置不一致或版本混用：
- 主库 MySQL 5.5 或更低 → 没有
binlog_checksum，binlog 无 checksum 字段；从库 5.6+ 若设slave_sql_verify_checksum = ON，会直接报 checksum mismatch 并停止复制 - 主库设
binlog_checksum = NONE，但从库设slave_sql_verify_checksum = ON→ 同样报错，因为从库期待 checksum 字段却没读到 - 使用
mysqlbinlog --base64-output=DECODE-ROWS查看 binlog 时，CRC32校验字段不会显示，但解析工具内部仍会校验；若手动编辑过 binlog 再重放，必然触发校验失败 - GTID 模式下，
binlog_checksum不影响 GTID 分配逻辑，但校验失败会导致Retrieved_Gtid_Set和Executed_Gtid_Set出现偏差，需人工干预
生产环境建议配置与注意事项
只要主从都是 MySQL 5.6.2 及以上，就应保持 binlog_checksum = CRC32（默认值），且不建议改为 NONE。
- 主库确认：
SELECT @@binlog_checksum;返回CRC32 - 从库确认：
SELECT @@slave_sql_verify_checksum;返回ON - 升级主从时，务必先升从库再升主库，避免新从库无法兼容老主库的无校验 binlog
- 物理备份（如 xtrabackup）恢复出的实例，
binlog_checksum值继承自备份时的配置，需检查是否与当前主库一致
真正容易被忽略的是：校验失败不会自动重试或跳过，而是硬性中止 SQL 线程——这意味着监控 Seconds_Behind_Master 突然变为 NULL 或 Slave_SQL_Running: No 时，第一反应不该是查延迟，而应立刻看 SHOW SLAVE STATUS\G 里的 Last_IO_Error 和 Last_SQL_Error。
