binlog_checksum配置不一致导致mysqlbinlog解析失败，主库设crc32而低版本客户端无法识别校验字段，报“sanity check failed”等错误；应优先使用同版本或更高版本mysqlbinlog工具，或临时关闭校验（set global binlog_checksum = none）并flush binary logs切换日志。
binlog_checksum 配置不一致导致 mysqlbinlog 解析失败
MySQL 5.6.6+ 默认开启 binlog_checksum = CRC32，但低版本客户端（如 MySQL 5.5 的 mysqlbinlog）或降级后未同步配置的实例，会因校验和字段无法识别而报错：Error in Log_event::read_log_event(): 'Sanity check failed' 或 checksum mismatch。这不是文件损坏，是协议层面的兼容性问题。
关键判断点：错误出现在解析开头、所有 event 都无法读取、且主库 SHOW VARIABLES LIKE 'binlog_checksum' 返回 CRC32，而你用的 mysqlbinlog 版本低于主库版本。
- 优先用与主库**同版本或更高版本**的
mysqlbinlog工具——它能正确处理 CRC32 校验和字段 - 若必须用旧版工具，临时关闭主库校验和（仅限诊断，勿长期关闭）：
SET GLOBAL binlog_checksum = NONE;，再执行FLUSH BINARY LOGS切换到新文件 - 注意：
binlog_checksum = NONE不影响已写入的旧 binlog 文件结构，只对后续新生成的 event 生效 - MySQL 8.0+ 若还启用了
binlog_transaction_compression = ON，解析时必须加--binlog-transaction-compression参数，否则仍会解析失败
从库 relay log 因 checksum 失败中断复制
当从库 SQL 线程报错 Relay log read failure: Event crc check failed，说明中继日志在写入或读取时校验失败。这通常不是 relay log 文件本身损坏，而是主库 binlog 发送过程中校验和被截断、网络丢包，或从库 relay_log_recovery 未启用导致状态不一致。
不要手动删 relay log 文件——relay-log.index 和实际文件名强绑定，删一个就全乱。
- 确认从库是否启用
relay_log_recovery = ON（5.7+ 默认 OFF，需显式设置），这是自动重建 relay log 的前提 - 停掉复制：
STOP SLAVE; - 清空 relay log：
RESET SLAVE ALL;（该命令会删除relay-log.index和所有 relay log 文件，并重置复制坐标） - 重启 mysqld（仅当
relay_log_recovery = ON时才有效）——启动时会自动拉取缺失的 binlog 重建 relay log - 如果无法重启，且知道当前正确的
Relay_Master_Log_File和Exec_Master_Log_Pos，可用CHANGE MASTER TO ... FOR CHANNEL ''手动重设位置后START SLAVE
磁盘/临时空间不足引发的 checksum 相关假象错误
mysqlbinlog 解析大 binlog（如 >4GB）时，若系统 TMPDIR 指向的空间不足，会先写临时解压/缓存文件，再做 checksum 验证。此时报错可能表现为：ERROR: Error in Log_event::read_log_event(): 'read error' 或直接 No space left on device，容易误判为校验和损坏。
重点：这个错误和 binlog_checksum 设置无关，但现象高度相似——都是解析卡在某个 offset 后 abort。
- 检查当前
TMPDIR路径：echo $TMPDIR；若为空，则默认用/tmp - 切到有足够空间的路径并导出变量：
export TMPDIR="/data1/tmp"（确保目录存在且 mysql 用户有读写权限） -
mysqlbinlog**不读取 MySQL 配置文件中的tmpdir**，只认系统环境变量 - 验证是否生效：运行
mysqlbinlog --base64-output=DECODE-ROWS -v /path/to/binlog | head -20，看能否输出前几行 event
跳过单个损坏 event 仅用于定位，不能用于恢复
有人看到 --force-read 就以为能“绕过损坏继续同步”，这是危险误解。mysqlbinlog --force-read 只在**本地解析诊断**时有用，它会让工具忽略单个 event 的校验失败继续往后读，但输出内容不可信——跳过的 event 可能包含事务边界、GTID、表结构变更等关键信息。
线上复制中绝不能靠它“硬顶”。一旦 Last_SQL_Error 提示 checksum 相关错误，说明 relay log 已不可信，必须重建。
-
--force-read的唯一安全用途：快速定位损坏位置，比如配合grep -B 5 "at [0-9]\+"找到最后一个合法 position - 若
mysqlbinlog --force-read连第一个 event 都读不出来（报 magic number 错），基本可判定文件头部损坏，无修复价值 - 主库 binlog 损坏但从库完好？别修主库日志——用从库数据反向重置主库 binlog 状态更安全
