最常见原因是主库binlog被清理而从库relay_master_log_file仍指向已删除文件，导致io线程失败报“could not find first log file name”；需先确认主库是否真丢失该binlog，再通过change master to重设为现存最新binlog位置。
主库 binlog 被删或过期，从库报 “Could not find first log file name”
这是最典型的 binlog 丢失现象，从库 IO 线程启动时请求的 master_log_file 在主库上已不存在。常见原因包括：RESET MASTER 被误执行、磁盘空间告警后直接 rm -f /var/lib/mysql/mysql-bin.*、expire_logs_days 设置过小（比如设为 1）且未及时归档。
此时无法用 binlog 做增量恢复，必须重做从库：
- 在主库执行一次全量备份（推荐
xtrabackup --backup，比mysqldump更适合大库） - 将备份恢复到从库，并确保
gtid_purged或master_log_pos与备份一致 - 用
CHANGE MASTER TO ... MASTER_AUTO_POSITION=1（GTID 模式）或指定新 binlog 文件名和 position（传统模式）重新配置复制
从库 relay log 损坏但主库 binlog 完好
relay log 是从库 IO 线程拉取并写入的本地副本，损坏后 SQL 线程会卡住，错误类似 Relay log read failure: Could not parse relay log event entry。只要主库 binlog 还在，就不用重搭。
安全做法是跳过损坏段，让从库重新拉取：
- 停掉从库：
STOP SLAVE; - 清空 relay log：
RESET SLAVE;（注意：这会清除master.info，需手动CHANGE MASTER TO重新指定） - 或更精准地：用
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=12345;指向当前主库最新位置，再START SLAVE;
关键点：不要手动删除 relay-log.index 或 .0000xx 文件，MySQL 自身管理更可靠。
ROW 格式下误删数据，但 binlog 里找不到 DELETE 行记录
不是 binlog 丢了，而是你没看对地方。ROW 格式不记录 SQL 文本，DELETE 操作对应的是 Delete_rows_event，直接 cat 或 grep "DELETE" 是搜不到的。
正确解析方式：
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012解析，输出中会明确标出### DELETE FROM `db`.`table`和前后镜像 - 如果只关心某张表，加
--database=db_name缩小范围 - 若时间点模糊，先用
mysqlbinlog --no-defaults --base64-output=DECODE-ROWS -v --start-datetime="2026-09-30 10:00:00" mysql-bin.000012 | head -n 50快速确认事件是否存在
注意：--base64-output=DECODE-ROWS 必须加，否则 Delete_rows_event 会显示为 base64 编码的乱码，根本没法定位。
GTID 模式下 binlog purge 导致从库无法追上
当主库执行 RESET MASTER 或 SET GLOBAL gtid_purged = '...' 清空 GTID 集合后，从库报错 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires。
这意味着从库缺失的事务在主库已不可追溯——GTID 不可逆，purge 后无法“找回”。此时唯一出路是：
- 确认从库缺失的 GTID 区间（从
SHOW SLAVE STATUS\G的Retrieved_Gtid_Set和Executed_Gtid_Set对比得出） - 若该区间事务有独立备份或日志存档，可人工补数据
- 否则只能停写主库，全量重建从库，避免主从长期不一致
日常必须禁用 RESET MASTER，改用 PURGE BINARY LOGS BEFORE '2026-09-25 00:00:00' 按时间安全清理；GTID 模式下，gtid_purged 只能追加不能覆盖。
