不能直接在主库跑mysqldump做基线备份，因其加--single-transaction仍会延长事务、膨胀undo log、加剧锁等待并拖慢复制；tb级导出耗时数小时，导致binlog持续推进、从库追不上而断连，且sql恢复无法并行，增量追平不可控。
为什么不能直接在主库上跑 mysqldump 做基线备份
主库通常承载写入和关键查询，mysqldump 即使加了 --single-transaction，也会拉长事务生命周期，导致 undo log 膨胀、锁等待加剧，甚至拖慢复制延迟。TB 级数据导出可能持续数小时，期间主库 binlog position 持续推进，从库追不上就容易断连。更麻烦的是，mysqldump 输出的 SQL 是串行执行的，恢复时无法并行，基线越晚，后续增量追平时间越不可控。
推荐做法：用 xtrabackup 在从库停 SQL 线程后做物理基线
这是生产环境最稳妥的组合——利用从库已有数据副本，规避主库压力，同时获得物理备份的速度与一致性保障。
- 先确认从库已同步完成：
SHOW SLAVE STATUS\G中Seconds_Behind_Master为0，且Slave_IO_Running和Slave_SQL_Running都是Yes - 暂停从库应用日志：
STOP SLAVE SQL_THREAD;（保留 I/O 线程继续拉取 binlog，避免主库 binlog 被 purge） - 立刻执行备份：
xtrabackup --backup --target-dir=/backup/base_$(date +%F_%H%M)/ --no-timestamp - 备份完成后，立即恢复 SQL 线程：
START SLAVE SQL_THREAD;，避免延迟积累 - 记录当前 binlog 位置：
SHOW SLAVE STATUS\G中的Relay_Master_Log_File和Exec_Master_Log_Pos，这个点就是基线对应的“一致位点”
xtrabackup 备份后必须 --prepare 才能恢复
物理备份只是文件拷贝，InnoDB 数据页可能处于不同 checkpoint 状态，不做 prepare 直接恢复会报错 innodb_page_size mismatch 或启动失败。这步不能跳过，也不能等到恢复时再补。
- 执行：
xtrabackup --prepare --target-dir=/backup/base_2026-08-11_2340/ - 注意：prepare 过程是只读的，不修改原备份目录，但会生成
xtrabackup_info和xtrabackup_checkpoints文件，后者明确标注了backup_type = full-prepared和to_lsn - 如果之后要做增量备份，必须用这个 prepared 后的目录作为
--incremental-basedir
基线备份必须包含 binlog 位点信息，否则增量无法衔接
单纯有物理文件不够，恢复后要能接上后续变更，就必须知道这个备份对应主库哪一刻的状态。只靠 SHOW SLAVE STATUS 记录的 Exec_Master_Log_Pos 不够保险——它反映的是从库执行到的位置，不是主库写入时刻。
- 更可靠的做法：备份前在主库执行
FLUSH BINARY LOGS;，然后查SHOW MASTER STATUS;，把File和Position一起记进备份目录的 README - 或者，在从库执行
STOP SLAVE SQL_THREAD;后立刻运行：mysql -e "SELECT @@global.gtid_executed;"（如果启用了 GTID），GTID 集合比 file/pos 更健壮 - 别依赖
mysqldump --master-data=2，它只适用于逻辑备份场景，对 xtrabackup 物理备份无意义
