直接从主库全量同步会拖垮主库io和cpu，因mysqldump持全局快照致undo log膨胀，xtrabackup热备则使io飙升90%+，且备份传输与单线程回放易致seconds_behind_master数小时起步，binlog清理激进还可能引发起始日志缺失错误。
直接从主库全量同步会拖垮主库 IO 和 CPU，尤其数据量超过 100GB 时，mysqldump 或 xtrabackup 在线备份都可能引发慢查询堆积、连接超时甚至主库响应卡顿。稳妥的做法是“从旧从库拉数据”，前提是旧从库本身已与主库强一致、延迟稳定在秒级内。
为什么不能直接从主库 dump 大库？
不是技术上做不到，而是生产环境里代价太高：
-
mysqldump --single-transaction会持有一个全局一致性快照，对大表（比如几百 GB 的订单表）执行期间，undo log持续膨胀，可能触发磁盘告警或事务回滚失败 -
xtrabackup虽支持热备，但备份过程持续读取主库数据文件 + binlog，IO 利用率常飙到 90%+，直接影响线上写入吞吐 - 备份文件传输耗时长，恢复阶段从库需重放全部 DDL/DML，SQL 线程单线程回放极易积压，
Seconds_Behind_Master动辄数小时起步 - 主库
binlog清理策略若激进（如只保留 3 天），备份窗口稍一拉长，新从库启动后可能因找不到起始 binlog 文件而报错Could not find first log file name in binary log index file
从旧从库拷贝数据的实操要点
这个方案本质是复用旧从库已有的数据快照 + 中继日志位置，跳过主库压力环节。但它对旧从库状态有硬性要求：
- 旧从库必须处于
Slave_IO_Running: Yes且Slave_SQL_Running: Yes，Seconds_Behind_Master≤ 5 秒（可通过SHOW SLAVE STATUS\G验证） - 拷贝前需在旧从库执行
STOP SLAVE;，确保 relay log 停在一致位置；否则中继日志末尾可能截断，新从库启动后无法续接 - 拷贝目录必须完整：至少包括
/var/lib/mysql/（含ibdata1、ib_logfile*、各库子目录）、relay-log.info、mysql-relay-bin.*文件，缺一不可 - 新从库的
server-id必须与主库、旧从库三者互异，例如主库为1、旧从库为2，则新从库设为3或更大整数，写入my.cnf后重启 mysqld
新从库启动后必须验证的三件事
拷贝完、改完配置、启动 mysqld 只是第一步。真正决定是否“可用”的是这三项检查：
- 执行
START SLAVE;后，立刻查SHOW SLAVE STATUS\G，确认Relay_Master_Log_File和Exec_Master_Log_Pos与旧从库停服前的值完全一致——这说明中继日志被正确识别并续接 - 观察
Seconds_Behind_Master是否从 0 开始缓慢增长（正常），而非长期卡在某个大数值（说明 SQL 线程卡住或 relay log 损坏） - 在主库执行一条带明显特征的写入，例如
INSERT INTO test_sync VALUES (UNIX_TIMESTAMP(), 'new_slave_test');，30 秒内检查新从库该表是否同步出现——这是端到端链路通的最简验证
最容易被忽略的是 relay log 文件权限问题：scp 拷贝后，新从库的 mysql 用户可能无权读取 mysql-relay-bin.000001 等文件，导致 IO 线程反复报错 Failed to open the relay log。务必在启动前运行 chown -R mysql:mysql /var/lib/mysql/ 并检查 SELinux 状态（如启用需 restorecon -Rv /var/lib/mysql）。
