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(推荐 8.0+ 版本)
二、部署步骤(主库: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:从库清空原有数据(重要)
全量备份恢复前需清空从库数据目录和 Binlog 目录,避免数据冲突:
# 关闭从库 MySQL /etc/init.d/mysql.server stop # 清空数据目录(确认路径正确!) rm /data/mysql/data/* -rf # 清空 Binlog 目录 rm /data/mysql/binlog/* -rf
生产环境注意:清空前需备份从库原有数据

步骤 4:从库恢复备份(三阶段)
Xtrabackup 恢复需经过「解压 → 准备 → 复制」三个关键步骤:
- 解压备份文件:
cd /data/backup/recover xbstream -x .xbstream
- 准备备份(一致性校验):
xtrabackup --prepare --target-dir=./
- 作用:修复备份中的不一致数据,确保恢复后的数据可用
- 复制数据到从库数据目录:
xtrabackup --defaults-file=/data/mysql/conf/my.cnf --copy-back --target-dir=./
步骤 5:启动从库并配置主从复制
修改数据目录权限:
MySQL 数据目录必须属于
mysql用户,否则无法启动:
chown -R mysql:mysql /data/mysql
- 启动从库并验证:
/etc/init.d/mysql.server start ps -ef | grep mysql # 查看进程是否正常

提取 Binlog 位点:
备份文件中包含
xtrabackup_binlog_info,记录备份时的同步起点:
cat /data/backup/recover/xtrabackup_binlog_info # 输出示例:mysql-bin.000029 196(Binlog 文件+位点)

- 配置主从关系并启动复制:
-- 从库执行 SQL 命令(替换为实际位点) CHANGE MASTER TO MASTER_HOST='192.168.184.151', MASTER_USER='repl', MASTER_PASSWORD='Uid_dQc63', MASTER_LOG_FILE='mysql-bin.000029', # 从 xtrabackup_binlog_info 提取 MASTER_LOG_POS=196; # 从 xtrabackup_binlog_info 提取 -- 启动复制 start slave;

步骤 6:验证主从同步状态
- 查看复制状态:
SHOW SLAVE STATUS\G
关键指标(需均满足):
Slave_IO_Running: Yes(IO 线程正常)Slave_SQL_Running: Yes(SQL 线程正常)Seconds_Behind_Master: 0(无延迟)

- 数据同步测试:
-- 主库插入测试数据 INSERT INTO maria.repl_test SELECT 2; -- 从库查询验证(应返回 id=1 和 id=2) SELECT * FROM maria.repl_test;

三、核心对比:两种主从部署方式
| 部署方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 基于位点(mysqldump) | 操作简单、无需额外工具 | 备份恢复慢、占空间大 | 中小规模(GB) |
| Xtrabackup | 热备份、速度快、省资源 | 需安装工具、步骤稍多 | 大规模数据库(>50GB) |
四、关键注意事项
- server_id 唯一性:主从架构中所有 MySQL 实例的 server_id 必须不同(主库建议设为 1,从库设为 2+)。
- Binlog 位点准确性:从 xtrabackup_binlog_info 提取位点,错误位点会导致同步失败。
- 数据目录权限:恢复后必须执行 chown -R mysql:mysql,否则 MySQL 启动报错。
- GTID 模式:本文基于传统位点复制,需关闭 GTID(gtid_mode=OFF);若使用 GTID,需调整配置并修改同步命令。
- 定期验证:部署后需定期执行 SHOW SLAVE STATUS\G 和数据测试,避免复制中断。
总结
Xtrabackup 凭借热备份、高效能的优势,完美解决了大规模 MySQL 数据库的主从复制部署痛点。遵循「备份 → 传输 → 恢复 → 配置 → 验证」的流程,结合关键注意事项,可快速搭建稳定的主从架构。建议根据数据量选择合适的部署方式,中小规模用 mysqldump,大规模优先 Xtrabackup。
到此这篇关于MySQL中Xtrabackup高效部署实现主从复制方案的文章就介绍到这了,更多相关MySQL Xtrabackup主从复制内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
mysql8.0 lower_case_table_names 大小写敏感设置问题解决
在默认情况下,这个变量是设置为0的,以保持向前兼容性,如果将该变量设置为1,则表名和数据库名将被区分大小写,本文主要介绍了mysql8.0 lower_case_table_names 大小写敏感设置问题解决,感兴趣的可以了解一下2023-09-09
MySQL两种表存储结构MyISAM和InnoDB的性能比较测试
MySQL两种表存储结构MyISAM和InnoDB的性能比较测试...2006-12-12
MySQL中IF()、IFNULL()、NULLIF()、ISNULL()函数的用法解读
这篇文章主要介绍了MySQL中IF()、IFNULL()、NULLIF()、ISNULL()函数的使用,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2025-06-06


最新评论