mysqlbinlog --verify-binlog-checksum 报错说明校验字段不匹配，可能因主库曾关闭binlog_checksum、非标工具中转导致event缺失或checksum被清零；该参数强制校验crc32，不加则默认跳过，无法发现静默损坏。
mysqlbinlog --verify-binlog-checksum 会报错说明什么
它不是告诉你“日志坏了”，而是告诉你“校验字段不匹配”——可能因为主库曾经关过 binlog_checksum，或用了非标准工具中转过 binlog，导致某段 event 缺失、截断或 checksum 字段被清零。错误信息通常是：ERROR: Invalid checksum in binary log 或解析中途退出并提示校验失败。
为什么必须加 --verify-binlog-checksum 才能发现损坏
默认情况下 mysqlbinlog 完全跳过 checksum 校验，即使 binlog 文件里带 CRC32 字段也视而不见。不加这个参数，你就等于用裸眼读一张带防伪码的发票却不验码——看起来条理清晰，实则可能整段 event 已静默损坏。
- MySQL 5.6.2+ 主库默认写入 checksum，但
mysqlbinlog默认不验证 - 只有显式加
--verify-binlog-checksum，工具才会在解析每个 event 前比对 CRC32 - 该参数在 MySQL 5.7+ 才支持；5.6 需升级客户端或改用其他校验方式（如手动 hexdump 对比）
实际验证命令怎么写才不踩坑
别只跑一条 mysqlbinlog mysql-bin.000001 就以为完事。完整验证要覆盖三个关键点：参数组合、路径权限、输出导向。
- 必须加
--verify-binlog-checksum，且建议搭配--base64-output=DECODE-ROWS --verbose，否则 row-based event 的 checksum 字段可能被跳过或误解析 - 文件路径要写绝对路径，避免因工作目录不同导致找不到文件或权限拒绝（尤其当 binlog 在
/var/lib/mysql/下时） - 不要直接终端输出大文件，用重定向到临时文件：
mysqlbinlog --verify-binlog-checksum --base64-output=DECODE-ROWS --verbose /var/lib/mysql/mysql-bin.000001 > /tmp/binlog_check.out 2>&1 - 检查返回值：
echo $?为 0 表示全程校验通过；非 0 则说明至少一个 event 校验失败
校验失败后下一步不是重试，而是定位源头
报错本身不指向“哪一行坏了”，只告诉你“从某个 position 开始校验崩了”。真正要盯住的是错误发生前最后几个 event 的 end_log_pos 和事件类型。
- 先用
mysqlbinlog --no-defaults --base64-output=DECODE-ROWS --verbose（不加校验）看崩溃点附近的原始结构，确认是否是Rotate_log_event或Format_description_event异常 - 检查主库当时的
SHOW VARIABLES LIKE 'binlog_checksum'历史记录，确认出问题的 binlog 是否生成于OFF时期 - 如果该 binlog 是从旧集群迁移过来的，优先怀疑中转脚本或备份工具（如 mydumper）是否 strip 了 checksum 字段
checksum 验证不是一次性开关，而是数据链路的“听诊器”——它不修复问题，但能让你在脏数据进入从库前就听见异常心跳。
