master_verify_checksum是mysql主库上控制binlog写入时是否强制校验并写入事件checksum的布尔变量，开启后可防止数据损坏被静默执行，但需主备两端校验开关一致且算法匹配。
master_verify_checksum 是什么，开了有啥用
它是个 MySQL 主库上的布尔型系统变量，控制主库是否在写入 binlog 时强制校验并写入事件 checksum。备库开启 slave_sql_verify_checksum=ON 后，会校验收到的事件 checksum 是否匹配——不匹配就报错中断复制，防止因网络传输、磁盘静默错误导致的 binlog 数据损坏被悄悄执行。
但注意：master_verify_checksum 默认是 ON（5.6.6+），不是 OFF；真正容易被忽略的是备库侧的校验开关没开，或者主备 checksum 算法不一致。
为什么主备切换后复制突然报错 ERROR 1594 (HY000)
典型现象：切换后新主库（原备库）开始写 binlog，旧主库（现备库）拉取时在 Relay_Log_Pos 处卡住，错误信息类似：Relay log read failure: Could not parse relay log event entry 或直接报 ERROR 1594 (HY000): Relay log read failure。
根本原因常是主备 checksum 行为不一致：比如原主库开了 master_verify_checksum=ON，但新主库（原备库）启动时没显式设置，又或用了不同 MySQL 版本，默认算法从 CRC32 切到 SHA256（5.7.29+ 支持），导致旧备库解析新主库发来的 binlog 时校验失败。
- 检查双方是否都显式设置了
master_verify_checksum=ON（主库）和slave_sql_verify_checksum=ON（备库） - 确认主备 MySQL 版本相同，或至少 checksum 算法兼容（
binlog_checksum值一致，推荐统一设为CRC32） - 切换前，在新主库上执行
SET GLOBAL binlog_checksum = 'CRC32';，并写入配置文件避免重启失效
配置文件里怎么写才不踩坑
不能只在主库配 master_verify_checksum，必须主备协同。这个变量本身只在主库生效，但它的效果依赖备库配合校验——所以配置重点其实是统一 binlog_checksum 和打开两端校验开关。
- 主库 my.cnf 加：
binlog_checksum = CRC32+master_verify_checksum = ON - 备库 my.cnf 加：
slave_sql_verify_checksum = ON（5.6+）或slave_checkpoint_verify_checksum = ON（5.7+，增强 checkpoint 校验） - 不要用
SET GLOBAL临时修改后不写配置——切换后服务重启就回退，checksum 不一致风险立刻暴露 - MySQL 8.0.20+ 已废弃
master_verify_checksum，改由binlog_checksum全局控制，此时只需确保主备binlog_checksum值完全一致
主备切换时最容易漏掉的三件事
很多人测了数据一致性、切了 VIP、启了新主库，结果一小时后复制崩了，问题就出在这些“小动作”没做。
- 切换前没在新主库上执行
FLUSH BINARY LOGS，导致旧 relay log 还残留着旧主库的 checksum 格式，新主库一写 binlog 就混杂两种格式 - 没检查
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否对齐——GTID 模式下 checksum 错误会导致 GTID gap，跳过会丢事务 - 用
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1切换后，忘了在新主库上执行RESET MASTER（仅限非 GTID 场景）或确认gtid_purged正确，否则旧 binlog 被 purge 后，备库重连可能找不到起点
checksum 不是万能锁，但它是一道关键防线。真正危险的不是它关着，而是开着却没对齐——那种“以为安全，其实裸奔”的状态最难排查。
