不能直接用mysqldump恢复的从库当新从库，因为mysqldump仅导出用户数据和表结构，不包含复制元数据（如master.info、slave_master_info表）、gtid执行集（@@global.gtid_executed）、binlog位点及relay log内容，导致恢复后复制无法准确定位，引发同步失败或主从冲突；必须先stop slave、reset slave all，并在gtid模式下手动设置gtid_purged后才能重建复制关系。
mysqldump 备份的从库不能直接拿来当新从库用
MySQL 从库（slave）自带复制元数据（master.info、relay-log.info、mysql.gtid_executed 等），如果直接用 mysqldump 备份再恢复到另一台机器，会丢失复制位点、GTID 状态，甚至引发主从冲突或启动失败。必须清理或重置这些状态，否则 START SLAVE 不会成功，或者同步一上来就报错 Could not execute Write_rows event on table... 或 Cannot replicate because the master's binlog position is invalid。
为什么不能直接用 mysqldump 恢复从库？
因为 mysqldump 默认只导出用户数据和表结构，不包含：
-
mysql.slave_master_info和mysql.slave_relay_log_info表（5.6+ 启用--skip-slave-start后才写入） - 当前 GTID set（
SELECT @@GLOBAL.gtid_executed） - binlog 文件名和 position（
SHOW MASTER STATUS输出） - 从库 relay log 实际内容（
mysqldump不读 relay log）
恢复后若没手动重置，MySQL 会尝试按旧位点拉取主库日志，但该位点可能已过期、被 purge，或根本不存在于当前主库 binlog 中。
恢复前必须做的三件事
在目标机器上执行恢复前，先确认并完成以下操作：
- 停掉从库复制：
STOP SLAVE; - 清空复制状态：
RESET SLAVE ALL;（注意：不是RESET SLAVE;，后者不删mysql.slave_*表） - 确认
gtid_mode=ON时，要记录原从库的gtid_executed，并在新实例初始化后用SET GLOBAL gtid_purged = '...';注入（否则CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1会失败）
如何用备份重建从库（GTID 模式下）
假设你用 mysqldump --all-databases --single-transaction --master-data=2 --triggers --routines --events 备份了原从库，且主库开启 gtid_mode=ON：
- 先在新机器上创建空白实例，启动 MySQL
- 导入备份：
mysql -u root -p - 导入后立即执行：
SET GLOBAL gtid_purged = '原从库的 gtid_executed 值';（必须在任何 DML 之前） - 再执行：
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION = 1; - 最后：
START SLAVE;
关键点：gtid_purged 必须严格等于原从库 SELECT @@GLOBAL.gtid_executed; 的输出值，多一个字符或少一个事务号都会导致 START SLAVE 报错 Lost connection to master 或卡在 Waiting for source to send event。
物理备份（XtraBackup）恢复从库更稳妥
如果原从库用了 Percona XtraBackup 备份，恢复后可直接保留复制信息（只要备份时加了 --slave-info）：
- 解压备份到新数据目录后，运行：
xtrabackup --prepare --apply-log-only（增量需多次 apply） - 启动前检查
xtrabackup_slave_info文件，它会给出类似：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=12345; - 启动 MySQL，执行该
CHANGE MASTER TO语句，再START SLAVE;
这种方式不用手动算 GTID、也不怕 mysqldump 漏掉系统表——因为它是文件级拷贝，mysql.slave_* 表、relay log、binlog index 全都原样保留。
mysqldump 备份的是逻辑快照，不是复制状态；XtraBackup 备份的是物理快照，但必须带 --slave-info 才能保位点。漏掉任一环节，新从库就只会报错、跳过、或同步错乱。
