确认中断是否由binlog丢失引发：先查Last_IO_Error是否为1236或“Could not find first log file name”，再在主库执行SHOW BINARY LOGS;比对最老log是否早于Relay_Master_Log_File，结合expire_logs_days等判断是否被清理，GTID下用MASTER_POS_WAIT验证；若确认丢失，则必须用mysqldump --master-data=2 --single-transaction全量备份，导入后需FLUSH TABLES WITH READ LOCK+SHOW MASTER STATUS获取实时位点，从库执行RESET SLAVE ALL后再CHANGE MASTER TO（GTID模式则设MASTER_AUTO_POSITION=1且禁用--set-gtid-purged=ON）。
确认中断是否真由 binlog 丢失引发
看到 SHOW SLAVE STATUS\G 中 Last_IO_Error 提示 Could not find first log file name 或错误码 1236，别急着 dump。先验证主库 binlog 是否真的不可用：
- 在主库执行
SHOW BINARY LOGS;，比对最老的Log_name是否早于从库Relay_Master_Log_File（来自SHOW SLAVE STATUS\G） - 查主库配置：
SELECT @@expire_logs_days, @@binlog_expire_logs_seconds;，结合中断时长判断是否被自动清理 - 翻主库错误日志，搜
Could not open log file，排除路径或权限问题 - GTID 模式下可快速验证：
SELECT MASTER_POS_WAIT('nonexistent-bin.000001', 0, 1);，返回NULL或超时即说明日志不可达
mysqldump 备份必须带 --master-data=2 和 --single-transaction
一旦确认 binlog 确实丢失，重建是唯一可靠路径。用 mysqldump 做全量备份时，漏掉关键参数会导致后续无法准确定位中继日志起点：
-
--master-data=2必须加：它把当前主库的MASTER_LOG_FILE和MASTER_LOG_POS作为注释写进 dump 文件，这是后续重设复制位点的原始依据 -
--single-transaction必须加：对 InnoDB 表做一致性快照，避免备份期间数据变动导致位点与数据错位；若库中含 MyISAM 表，得换用--lock-all-tables - 禁用
--skip-lock-tables：它会让--master-data记录的位置和实际导出的数据状态不一致 - 推荐加上
--routines --triggers --events，否则存储过程、触发器、事件不会导出 - 示例命令：
mysqldump -u root -p --all-databases --master-data=2 --single-transaction --routines --triggers --events > full.sql
导入后不能直接执行 dump 里的 CHANGE MASTER TO 注释
dump 文件里那行 # CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=1234567 只反映“dump 开始那一刻”的主库状态。而主库在你传输、导入期间持续写入，该位点早已过期：
- 导入前，在主库立刻执行
FLUSH TABLES WITH READ LOCK;，再SHOW MASTER STATUS;，记下实时File和Position - 导入完成后，在从库执行
STOP SLAVE;，再RESET SLAVE ALL;（注意不是RESET SLAVE;），清空旧 relay log 和 master.info - 然后执行
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=1234567;，这里的MASTER_LOG_FILE和MASTER_LOG_POS必须是你刚在主库上查到的实时值 - 最后
START SLAVE;
GTID 模式下完全不用管文件名和位置，但必须设 MASTER_AUTO_POSITION=1
如果你的 MySQL 5.7 是 GTID 模式（gtid_mode=ON），上面所有基于 MASTER_LOG_FILE 和 MASTER_LOG_POS 的操作都无效。MySQL 会忽略它们，只认 GTID：
- dump 时必须用
--set-gtid-purged=OFF，否则 dump 文件头部会写入SET @@GLOBAL.GTID_PURGED，恢复时强制清空从库已执行的 GTID 集合，导致 START SLAVE 失败 - 导入后执行
CHANGE MASTER TO时，必须指定MASTER_AUTO_POSITION=1，且不能带MASTER_LOG_FILE或MASTER_LOG_POS - 确保从库
server-id唯一、read_only=1已设、复制账号权限正确 - 恢复后检查
SELECT @@GLOBAL.gtid_executed;是否与主库接近，再看Executed_Gtid_Set是否持续增长
真正容易被忽略的是：即使你用了 --master-data=2，只要没在主库锁表后立刻抓取实时位点，或者没执行 RESET SLAVE ALL; 清掉残留 relay log，从库就可能继续执行旧中继日志里的冲突语句，导致 START SLAVE 后秒报错。
