binlog损坏导致“found invalid event”错误，主因是磁盘故障、异常断电或强制kill mysqld；offset 123为损坏位置，--force仅跳过校验不修复文件，关键需定位源头并用change master to跳过损坏段或重置复制。
mysqlbinlog --force 读取时抛出 “found invalid event in binary log” 错误
这基本说明 binlog 文件已损坏，常见于磁盘故障、异常断电或强制 kill mysqld 进程后未正常 flush。错误里 error in log_event::read_log_event() 和具体 offset 123 是关键线索——损坏位置就在那个字节偏移点附近。
直接用 mysqlbinlog --force 尝试跳过无效事件，但要注意：--force 不会修复文件，只是让解析器忽略校验失败继续往后读；若损坏在文件开头（如 offset
- 优先尝试加
--force-if-open：比--force更激进，适用于 binlog 正被 mysqld 写入但未关闭的场景 - 若知道大致损坏区间（比如从监控发现某次
SHOW BINARY LOGS后日志大小突变），可用--start-position=XXX跳过前段，例如mysqlbinlog --start-position=200 mysql-bin.000005 - 避免对损坏文件直接重写：不要用
> repaired.sql覆盖原文件，先输出到新路径，保留原始mysql-bin.000005备查
从 SHOW SLAVE STATUS 看出 Seconds_Behind_Master 持续增长且 IO_Running=Yes / SQL_Running=No
这是主从中断的典型表征，结合 Last_SQL_Errno 值为 1594 或 1677，基本可锁定是 relay log 或本地 binlog 解析失败。但注意：1594 表示从库在重放时遇到无法识别的 event（常因主库 binlog 损坏），而 1677 表示行格式不匹配（多见于主从 binlog_format 不一致，非损坏）。
此时别急着重置，先确认问题源头是否在主库：
- 登录主库执行
SHOW MASTER STATUS，记下当前File和Position - 在从库上运行
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000005 | head -n 50，看能否解析出合法 event（如Query、Write_rows） - 若解析失败，再检查该 binlog 是否被
expire_logs_days自动清理过，或被人工RESET MASTER清空过——这种“消失”不是损坏，而是日志已不存在
用 CHANGE MASTER TO 跳过损坏位置重设复制起点
确定损坏发生在主库某个 binlog 的中间位置（比如 mysql-bin.000005 的 position 123～8900 之间），且你有把握跳过这段不影响业务一致性，就可以手动推进从库的读取位点。
操作前必须停掉 SQL 线程：STOP SLAVE SQL_THREAD;，否则 CHANGE MASTER TO 会被拒绝。
- 假设主库当前最新日志是
mysql-bin.000006，position 是1987，而mysql-bin.000005在 offset 123 损坏，则应把从库指向mysql-bin.000006开头：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=4;（所有 binlog 文件起始 position 都是 4） - 如果损坏的是最新正在写的那个文件（如
mysql-bin.000006），且你确认主库已无新写入（比如刚重启过），可先FLUSH LOGS切出新文件，再用SHOW MASTER STATUS查新文件名和初始 pos -
MASTER_LOG_POS必须是合法 event 起始点，不能随便填。用mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000006 | grep '^# at ' | head -n 3查前几个# at XXX行，选最小的那个（通常是 4）
reset master 后从库报 “Could not find first log file name in binary log index file”
这是最易踩的坑：主库执行 RESET MASTER 会清空 mysql-bin.index 并新建 mysql-bin.000001，但从库的 relay-log.info 或 master.info 里还存着旧的 mysql-bin.000005 记录，导致 IO 线程启动时找不到对应文件。
此时不能直接删 relay-log.info，而应走标准重连流程：
- 在从库执行
STOP SLAVE;，然后RESET SLAVE ALL;（注意是ALL，它会清空所有复制元数据，包括master.info） - 再用
CHANGE MASTER TO重新指定主库地址、用户、密码，以及新的MASTER_LOG_FILE和MASTER_LOG_POS（即mysql-bin.000001和4） - 最后
START SLAVE;，观察SHOW SLAVE STATUS\G中IO_Running和SQL_Running是否都为Yes
真正麻烦的不是损坏本身，而是你不确定那段损坏区间里有没有关键事务——比如一个跨多表的转账操作只写了一半。这种情况下，靠偏移量硬跳，可能让从库数据永久不一致。
