【MySQL】使用 Xtrabackup 创建主从复制
在 MySQL 主从复制部署中，mysqldump 适合中小规模数据库，但面对超大规模数据（>50GB）时，备份恢复效率低下。Percona Xtrabackup 作为开源热备份工具，具备备份速度快、占用资源少、不影响业务运行的优势，是大规模数据库主从复制的优选方案。本文将详细讲解基于 Xtrabackup 的主从复制完整部署流程。
一、前置准备
- 主从服务器已安装 MySQL（版本一致）
- 主从服务器网络互通（开放 MySQL 端口 3306、SCP 传输端口 22）
- 主库已创建复制用户（
repl）并授权：CREATE USER 'repl'@'192.168.184.%' IDENTIFIED BY 'Uid_dQc63'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.184.%'; FLUSH PRIVILEGES; - 主从服务器安装 Xtrabackup
二、部署步骤（主库：192.168.184.151；从库：192.168.184.152）
步骤 1：主库执行全量备份
Xtrabackup 直接复制数据文件并记录 Binlog 位点，支持流模式输出备份文件（适合大文件传输）：
# 主库执行备份命令（需输入 root 密码）
xtrabackup --defaults-file=/data/mysql/conf/my.cnf -uroot -p \
--backup --stream=xbstream --target-dir=./ > /data/backup/xtrabackup_bak/xtrabackup.xbstream- 备份文件保存路径：
/data/backup/xtrabackup_bak/xtrabackup.xbstream - 核心参数：
--stream=xbstream流式输出，减少磁盘占用
步骤 2：备份文件传输至从库
使用 SCP 传输备份文件，从库需提前创建接收目录：
# 从库创建目录（若不存在）
mkdir -p /data/backup/recover
# 主库执行传输命令
scp /data/backup/xtrabackup_bak/xtrabackup.xbstream 192.168.184.152:/data/backup/recover
步骤 3：从库清空原有数据（重要）
由于 Xtrabackup 备份是全量数据，需先清空从库原有数据目录和 Binlog 目录，避免数据冲突：
（1）关闭从库 MySQL
/etc/init.d/mysql.server stop（2）清空数据目录
# 清空从库数据目录（需确认路径正确性）
rm /data/mysql/data/* -rf
# 清空从库Binlog目录
rm /data/mysql/binlog/* -rf生产环境注意：清空前需备份从库原有数据
步骤 4：从库恢复备份（三阶段）
Xtrabackup 备份恢复需经过解压备份、准备备份、复制数据三个步骤。
（1）解压备份文件
进入从库备份目录，使用xbstream工具解压备份：
cd /data/backup/recover
xbstream -x < xtrabackup.xbstream（2）准备备份（一致性校验）
xtrabackup --prepare --target-dir=./- 作用：修复备份中的不一致数据，确保恢复后的数据可用
（3）复制备份数据到从库数据目录
将准备好的备份数据复制到从库 MySQL 数据目录：
xtrabackup --defaults-file=/data/mysql/conf/my.cnf --copy-back --target-dir=./步骤 5：启动从库并配置主从复制
恢复数据后，需修改数据目录权限，启动从库，并配置主从复制关系。
（1）修改数据目录权限
MySQL 数据目录需属于mysql用户，否则无法启动：
chown -R mysql:mysql /data/mysql（2）启动从库 MySQL
/etc/init.d/mysql.server start
# 验证MySQL是否启动成功
ps -ef | grep mysql
（3）提取备份时的 Binlog 位点
Xtrabackup 备份会生成xtrabackup_binlog_info文件，记录备份时的 Binlog 位点：
cat /data/backup/recover/xtrabackup_binlog_info输出结果类似：mysql-bin.000029 196，即 Binlog 文件为mysql-bin.000029，位点为196。
（4）配置主从关系并启动复制
与基于位点的复制步骤一致，在从库配置主库信息并启动复制：
# 配置主从关系（替换为实际位点）
CHANGE MASTER TO
MASTER_HOST='192.168.184.151',
MASTER_USER='repl',
MASTER_PASSWORD='Uid_dQc63',
MASTER_LOG_FILE='mysql-bin.000029',
MASTER_LOG_POS=196;
# 启动复制
start slave;
步骤 6：验证与测试同步
同样通过SHOW SLAVE STATUS\G验证复制状态（Slave_IO_Running和Slave_SQL_Running均为Yes，Seconds_Behind_Master为0），并在主库插入测试数据验证同步：
# 主库插入测试数据
insert into maria.repl_test select 2;
# 从库验证
select * from maria.repl_test; # 应查询到id=1和id=2
三、核心对比：两种主从部署方式
| 部署方式 | 优点 | 缺点 | 适用场景 |
| 基于位点（mysqldump） | 操作简单、无需额外工具 | 备份恢复慢、占用磁盘空间大 | 中小规模数据库（数据量 < 50GB） |
| Xtrabackup | 热备份、速度快、占用资源少 | 需安装额外工具、步骤稍复杂 | 大规模数据库（数据量 > 50GB） |
四、关键注意事项
- server_id 唯一性：同一主从架构中所有实例的
server_id必须不同，否则复制会失败； - Binlog 位点准确性：基于位点的复制中，位点错误会导致从库同步异常，需从备份文件中准确提取；
- 数据目录权限：Xtrabackup 恢复后需确保数据目录属于
mysql用户，否则 MySQL 无法启动； - GTID 模式：本文基于传统位点复制，需关闭 GTID；若使用 GTID 复制，需调整相关配置（如
gtid_mode=on）； - 定期验证：主从复制部署后，需定期通过
SHOW SLAVE STATUS\G和数据测试验证同步状态，避免复制中断。
总结
Xtrabackup 凭借热备份、高效能的优势，完美解决了大规模 MySQL 数据库的主从复制部署痛点。遵循「备份 → 传输 → 恢复 → 配置 → 验证」的流程，结合关键注意事项，可快速搭建稳定的主从架构。建议根据数据量选择合适的部署方式，中小规模用 mysqldump，大规模优先 Xtrabackup。
