主从同步中断后不能直接start slave，必须确认binlog位点或gtid集合一致性；mysqldump需根据模式选--set-gtid-purged=off（gtid模式禁用gtid_purged写入）或--master-data=2（传统模式记录file/pos注释），二者互斥，且恢复前须stop slave; reset slave all; gtid模式下change master to必须设master_auto_position=1。
主从同步中断后，不能直接 start slave 就完事——必须确认从库是否还持有与主库一致的 BINLOG 位点或 GTID 集合，否则大概率报错或跳过数据。
为什么 mysqldump 备份后要加 --set-gtid-purged=OFF 或 --master-data=2
这两个参数决定从库恢复后“从哪里开始同步”：
-
--set-gtid-purged=OFF：告诉 MySQL 不要在 dump 文件头部写入SET @@GLOBAL.GTID_PURGED。否则恢复时会强制清空从库已执行的 GTID 集合，导致后续START SLAVE因 GTID 冲突失败（错误如ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository） -
--master-data=2：在 dump 文件里插入CHANGE MASTER TO所需的MASTER_LOG_FILE和MASTER_LOG_POS注释（带#），但不会自动执行；你得手动SOURCE后再CHANGE MASTER TO ... MASTER_AUTO_POSITION=0，适用于非 GTID 模式 - 二者不能共存——GTID 模式下必须用
--set-gtid-purged=OFF，传统 pos 模式才用--master-data=2
恢复前必须停掉 SQL 线程并重置复制状态
直接 SOURCE 备份后就 START SLAVE，极大概率触发 Last_SQL_Errno: 1062（主键冲突）或 1032（记录找不到），因为中继日志（relay log）里还残留旧的未执行事件。
- 先执行
STOP SLAVE; - 再执行
RESET SLAVE ALL;（注意不是RESET SLAVE;）——它会清空master.info、relay-log.info及所有 relay log 文件，避免旧位点干扰 - 如果用了 GTID，还需确认从库
SELECT @@GLOBAL.gtid_executed;是否为空；若不为空，且你又用了--set-gtid-purged=OFF，那恢复后START SLAVE会从当前 GTID 集合之后继续拉取，这是预期行为
GTID 模式下 CHANGE MASTER TO 必须指定 MASTER_AUTO_POSITION=1
哪怕你 dump 时用了 --master-data=2 并记下了 File/Position，在 GTID 模式下硬填 MASTER_LOG_FILE 和 MASTER_LOG_POS 是无效的，MySQL 会忽略它们。
- 正确写法：
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1; - 错误写法：
CHANGE MASTER TO ... MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1234;（MySQL 5.7 会静默忽略这两个参数，仍按 GTID 恢复，但容易让人误判） - 验证是否生效：
SHOW SLAVE STATUS\G中看Auto_Position: 1和Retrieved_Gtid_Set是否开始增长
备份文件导入后权限和时间戳容易被忽略
mysqldump 导出的是 SQL 文本，SOURCE 执行时走的是 MySQL 协议，不涉及文件系统权限——但如果你用的是 mysql 方式导入，且备份里含 <code>CREATE DATABASE 或 DROP TABLE，要注意用户权限是否足够；更重要的是：
- 从库
datadir下的 ibdata1、ib_logfile* 等 InnoDB 公共文件，不能被 mysqldump 触及；若主从表结构不一致（比如某张表用了ROW_FORMAT=COMPRESSED而从库不支持），SOURCE会卡在建表阶段，报错如ERROR 1031 (HY000): Table storage engine for 't1' doesn't have this option - 恢复后务必检查
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否持续为 0，且Slave_IO_Running和Slave_SQL_Running均为Yes；只要其中一个是No，就得看Last_IO_Error或Last_SQL_Error——90% 的问题都藏在这里，而不是备份本身
