主库非正常关机导致binlog末尾出现空洞，需通过mysqlbinlog检测损坏位置、flush logs切换新日志、利用未损坏binlog补全从库或重建从库恢复；空洞不可修复，必须绕过。
主库非正常关机（如断电、kill -9）后，binlog 文件末尾大概率出现空洞（invalid event、truncated event），直接用于从库恢复会触发 read_log_event 错误或复制中断——此时不能靠跳过或重试修复，必须识别并绕过损坏段。
确认 binlog 是否存在空洞
空洞不是“日志缺失”，而是文件末尾写入不完整导致解析失败。常见现象包括：mysqlbinlog 报错 found invalid event in binary log、error in log_event::read_log_event()，或 SHOW SLAVE STATUS 中 SQL thread 卡在某个 position 且报错类型为 1594 或 1677。
- 执行
SHOW MASTER LOGS;查看当前 binlog 列表，重点关注最后生成的文件（如mysql-bin.000012） - 用
mysqlbinlog --force-read -v mysql-bin.000012 | head -30测试能否读出有效事件；若开头就报 offset 错误（如offset 4），说明该文件从头损坏 - 若能读出前几条但中途卡住，说明是末尾空洞，需定位最后一个可用 event 的 position
停写 + 切换新 binlog 防止污染
只要主库还能启动，第一件事不是恢复，而是阻断进一步损坏：空洞文件一旦被后续事务追写，可能把损坏扩散到新事件中。
- 立即执行
FLUSH LOGS;，强制生成新 binlog（如mysql-bin.000013），后续所有写入都进新文件 - 检查
sync_binlog=1和binlog_checksum=CRC32是否启用；没开的现在就加进my.cnf并重启，否则下次断电照样空洞 - 临时禁止应用写入主库（如切走流量、设
SET GLOBAL read_only=ON;），避免新事务落进刚切换的文件还没来得及备份
从库恢复：用未损坏 binlog 补全，而非硬啃空洞文件
空洞文件不可信，但旧 binlog（如 mysql-bin.000001 到 mysql-bin.000011）只要没被 PURGE 或磁盘损坏，就是安全增量源。关键在于对齐位置。
- 从最近一次全量备份（如
mysqldump --master-data=2）中提取CHANGE MASTER TO的File和Position—— 这是起点 - 用
mysqlbinlog --start-position=XXX mysql-bin.00000Y提取起点之后、空洞文件之前的所有事件，导入从库（注意过滤掉SET @@SESSION.GTID_NEXT等非业务语句） - 如果空洞发生在最新文件开头（即整个
mysql-bin.000012不可用），则终点取上一个文件末尾 position：SHOW MASTER STATUS查mysql-bin.000011的Position - 跳过空洞文件本身：不要在
CHANGE MASTER TO中指定它，也不要尝试SET GLOBAL sql_slave_skip_counter—— skip_counter 对空洞无效，只会让 SQL 线程反复失败
重建从库是最省心的兜底方案
当空洞范围大、旧 binlog 不全、或从库已同步到空洞位置时，修复成本远高于重建。别试图拼接或跳过。
- 主库执行
FLUSH TABLES WITH READ LOCK;，记下SHOW MASTER STATUS输出（取最新完好的 binlog 文件名和 position） - 另起会话导出：
mysqldump --all-databases --single-transaction --master-data=2 > fresh.sql - 解锁：
UNLOCK TABLES;，立刻恢复主库写入 - 在新从库实例导入
fresh.sql，然后解析文件里注释行的CHANGE MASTER TO，去掉#执行（GTID 模式下改用RESET MASTER; SET GTID_PURGED=...）
空洞的本质是物理写入中断，不是逻辑错误；所有“修复”操作的前提是承认损坏不可逆——真正容易被忽略的，是误以为 mysqlbinlog 能绕过空洞解析，或者寄希望于从库 relay log 能补位。它们都不具备校验能力，强行使用只会把问题扩散到下游。
