用备份建从库的路径
用 XtraBackup 备份建从库是标准路径：源端做一次全备，把备份目录拷贝到新实例，prepare 后 copy-back 到数据目录，再从 xtrabackup_binlog_info 读出位点或 GTID，设置 gtid_purged，最后用 SOURCE_AUTO_POSITION 拉起复制。整个过程的关键是「GTID 集合必须原样设置」，抄错一位就会导致差集判断全错、数据静默缺失。相比逻辑导出，物理备份恢复速度更快，尤其适合几百 GB 以上的大实例，代价是备份文件与版本、页大小强绑定。
基本信息
| 源端备份 | xtrabackup --backup --target-dir=… |
|---|---|
| 准备阶段 | xtrabackup --prepare，让数据文件达到一致状态 |
| 恢复阶段 | xtrabackup --copy-back，数据目录必须为空 |
| 位点来源 | 备份目录下的 xtrabackup_binlog_info |
| 从库侧 | RESET MASTER 后设置 gtid_purged，再开启自动定位 |
典型使用场景
- 新建从库，避免直接压主库做逻辑导出
- 大实例重建时减少对主库的长时间影响
- 机房迁移时整体搬移数据
- 演练重建从库的完整流程与耗时
- 扩容时批量增加从库
备份与恢复
备份与恢复
# 源端：全备
xtrabackup --backup --user=backup --password='***' \
--target-dir=/data/backup/base_for_replica
cat /data/backup/base_for_replica/xtrabackup_binlog_info
# 形如：mysql-bin.000045 12345678 3a7f1e3b-...:1-5000000
# 新实例：prepare 并恢复
xtrabackup --prepare --target-dir=/data/backup/base_for_replica
xtrabackup --copy-back --target-dir=/data/backup/base_for_replica \
--datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql从库端拉起复制
从库端拉起复制
-- 启动实例后执行
RESET MASTER;
SET GLOBAL gtid_purged = '3a7f1e3b-1111-2222-3333-444455556666:1-5000000';
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='10.0.0.10', SOURCE_USER='repl', SOURCE_PASSWORD='***',
SOURCE_AUTO_POSITION = 1;
START REPLICA;
SHOW REPLICA STATUS\G阶段与注意
| 阶段 | 命令 | 注意事项 |
|---|---|---|
| 备份 | xtrabackup --backup | 记录备份起点的位点与 GTID |
| 准备 | xtrabackup --prepare | 让数据文件达到一致状态 |
| 恢复 | xtrabackup --copy-back | 数据目录必须为空 |
| GTID 设置 | SET GLOBAL gtid_purged | 必须与备份信息文件完全一致 |
| 拉起复制 | SOURCE_AUTO_POSITION=1 | 配合差集自动接续，不用手算位点 |
xtrabackup_binlog_info 里的 GTID 集合要原样使用。8.0 也可以在备份阶段用 --set-gtid-purged 相关选项让工具直接处理，但两种方式的语义不要混。恢复之前把这个文件的内容抄进变更单，事后核对时可以直接对照，不必再翻备份目录。
copy-back 之前数据目录必须为空：目录里已有旧文件时，工具要么直接报错，要么留下残留文件，让新实例带着旧数据启动。更稳的做法是使用一台干净机器，或者先把原数据目录整体挪走另存一份。
恢复完成后别忘修文件属主：属主不对会让 MySQL 启动失败，而错误信息通常只提示权限问题，不会明显指向目录归属。