主库物理断电导致binlog损坏（如报found invalid event、read_log_event错误）时，日志不可信，必须弃用损坏binlog，以最近全量备份为基线恢复；需先定位损坏文件、FLUSH LOGS切换新日志、停从库复制，再通过备份+未损坏旧binlog补全数据，或重建从库，并启用sync_binlog=1、binlog_checksum=CRC32等加固措施。
主库物理断电后重启，若导致 binlog 文件损坏（如解析报 found invalid event in binary log、error in log_event::read_log_event()），说明日志已不可靠，无法继续用于复制或逻辑恢复。此时不能强行跳过或重放，必须切换为“以备份为基线 + 丢弃损坏 binlog”的恢复路径。
第一步：确认损坏范围并停止错误传播
登录主库执行：
-
SHOW MASTER LOGS; 查看当前存在的 binlog 文件列表，定位疑似损坏的文件（如最后生成的
mysql-bin.0000xx） - mysqlbinlog --force-read -v mysql-bin.0000xx | head -50 测试是否能读出有效事件；若在开头就报错（如 offset 4 或 123 处 event_type 35），基本确认该文件从头损坏
- 立即执行 FLUSH LOGS; 切换到新 binlog，防止后续写入继续污染
- 检查从库状态：SHOW SLAVE STATUS\G，若 SQL 线程卡在损坏 binlog 的 position，STOP SLAVE 不再尝试重放
第二步：评估可恢复性，优先启用备份
损坏 binlog 意味着其中记录的事务无法可信重放，因此：
- 若存在最近全量备份（如
mysqldump --master-data=2 --single-transaction或 xtrabackup），且备份时间点早于断电时刻，则它是唯一可信数据源 - 检查 expire_logs_days 和磁盘空间，确认未损坏的旧 binlog（如
mysql-bin.0000xx-yy）是否仍存在——这些可用于补全备份后到断电前的增量 - 若无可用备份，且业务允许短时降级，可考虑从从库拉取当前一致数据（前提是该从库未同步到损坏位置，且 relay log 完整）
第三步：重建从库（最稳妥方式）
不修复、不跳过、不拼接，直接重建：
- 主库上加全局读锁：FLUSH TABLES WITH READ LOCK;，记下 SHOW MASTER STATUS 输出的 File 和 Position（取最新完好的 binlog 末尾）
- 另起会话导出：mysqldump --all-databases --master-data=2 --single-transaction > fresh_slave.sql
- 解锁：UNLOCK TABLES;
- 将 dump 文件导入新从库实例，然后解析
fresh_slave.sql中的CHANGE MASTER TO注释行，去掉#并执行（注意校验 GTID 是否启用） - START SLAVE; 后观察 Seconds_Behind_Master 是否持续下降，确认复制正常启动
第四步：后续加固措施
避免同类问题反复发生：
- 启用 sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1，确保事务提交即落盘
- 配置 binlog_checksum = CRC32，让 MySQL 在写入时校验 binlog 完整性
- 将 binlog 存放于带 UPS 的独立磁盘，或使用 rsync + inotify 实时同步 binlog 到备用节点
- 定期用 mysqlbinlog --verify-binlog-checksum 抽检 binlog 文件完整性
