MySQL 5.7 中 Percona XtraBackup (包含 innobackupex 工具) 支持远程备份。它可以通过流备份技术,直接将数据从本地服务器备份到远程服务器,无需在目标服务器安装 xtrabackup,特别适合本地磁盘空间有限的情况。
innobackupex --defaults-file=/etc/mysql/my.cnf \
--user=backup_user --password='password' \
--stream=xbstream /path/to/local/backup | \
ssh root@远程服务器IP "xbstream -x -C /path/to/remote/backup"
以下是针对数据库实例 IP(172.10.10.10)和备份服务器 IP(172.10.10.11)的远程备份详细解释及实操示例,帮助理解每个参数和步骤的作用:
1、命令参数详解
原命令结构拆解(对应示例 IP):
bash
innobackupex \
--defaults-file=/etc/my.cnf \ # 指定MySQL配置文件路径
--user=backup_user \ # 备份用户(需提前授权)
--password='Backup@123' \ # 备份用户密码
--stream=xbstream \ # 以xbstream格式流式传输(不落地存储)
/tmp/local_temp \ # 本地临时目录(仅用于临时处理,不存储完整备份)
| \ # 管道符:将本地输出传输到远程服务器
ssh root@172.10.10.11 \ # 通过SSH连接备份服务器
"xbstream -x -C /backup/mysql_remote" # 在远程服务器解压并存储备份
核心参数作用:
--stream=xbstream:启用流式备份模式,备份数据不写入本地磁盘,直接通过管道传输,节省本地空间。
xbstream -x -C /path:在远程服务器执行的命令,-x表示解压流数据,-C指定解压到目标目录(需提前创建)。
SSH 管道:利用 SSH 协议的安全性,将本地备份流加密传输到远程服务器,避免明文传输风险。
2、关键注意事项
-
临时目录作用:/tmp/local_temp
仅用于 xtrabackup 临时处理文件,不会存储完整备份(因为数据已通过流传输到远程),备份完成后可安全删除。
-
网络与性能:远程备份依赖网络带宽,建议在业务低峰期执行;若数据量大,可添加--compress
参数压缩传输(需在远程服务器用--decompress
解压)。
-
权限问题:
- 远程目录
/backup/mysql_remote
需确保root
用户有写入权限(或调整 SSH 登录用户为非 root,需同步修改目录权限)。
- 数据库文件权限在恢复时需改为
mysql:mysql
,否则 MySQL 无法读取。
-
中断处理:若备份中断,需删除远程服务器上的不完整文件后重新执行,避免残留文件导致恢复失败。
innobackupex --defaults-file=/etc/mysql/my.cnf \
--user=backup_user --password='password' \
--slave-info --stream tar /path/to/local/backup | \
ssh root@远程服务器IP "cat - > /path/to/remote/backup/backup.tar"
innobackupex --defaults-file=/etc/mysql/my.cnf \
--user=backup_user --password='password' \
--databases="db1 db2 db3" --stream=xbstream /path/to/local/backup | \
ssh root@远程服务器IP "xbstream -x -C /path/to/remote/backup"
注意:--databases 参数值要用引号括起来
-
停止 MySQL 服务:
mysqladmin -uroot -p shutdown
-
应用日志(在远程服务器上执行):
innobackupex --defaults-file=/etc/mysql/my.cnf \
--user=root --apply-log /path/to/remote/backup
-
还原数据文件:
# 使用--copy-back(适用于从库磁盘空间够大的情况)
innobackupex --defaults-file=/etc/mysql/my.cnf \
--user=root --copy-back /path/to/remote/backup
# 或使用--move-back(适用于空间紧张的情况)
innobackupex --defaults-file=/etc/mysql/my.cnf \
--user=root --move-back /path/to/remote/backup
-
修复权限并启动 MySQL:
chown -R mysql:mysql /path/to/mysql/data
service mysqld start
-
性能考虑:
- 远程备份会占用网络带宽,建议在业务低峰期执行
- 可以添加 --compress 选项压缩备份数据,减少传输带宽和存储需求
-
备份验证:
- 备份完成后,检查输出中是否包含 "completed OK!" 信息
- 定期测试恢复流程,确保备份的可用性
-
版本兼容性:
- 使用与 MySQL 5.7 兼容的 Percona XtraBackup 2.4 版本
- 主从服务器上的 xtrabackup 版本必须一致
-
安全建议:
- 为备份用户设置强密码并定期更换
- 考虑使用 SSH 密钥认证而非密码,增强安全性
- 限制备份用户的访问权限,仅授予必要的权限
使用 Percona XtraBackup 的远程备份功能,您可以高效地将 MySQL 5.7 数据库备份到远程服务器,无需担心本地磁盘空间不足的问题,同时保证备份过程中数据库的正常运行。建议根据业务需求制定定期备份策略,并定期测试恢复流程以确保备份的可靠性。
使用 Percona XtraBackup(含 innobackupex)进行恢复时,支持单独恢复单个库或单个表,但操作方式比逻辑备份(如 mysqldump)更复杂,且依赖数据库配置(如 InnoDB 的表空间管理方式)。以下是具体说明和操作思路:
能否高效恢复单个库 / 表,主要取决于 MySQL 的innodb_file_per_table
配置:
- 若启用
innodb_file_per_table=1
(推荐,MySQL 5.7 默认开启):每个 InnoDB 表会生成独立的表名.ibd
文件(数据 + 索引)和表名.frm
文件(表结构),此时单表 / 单库恢复可行性高。
- 若未启用(共享表空间):所有表数据存储在共享表空间(如
ibdata1
),单表恢复几乎不可行(需解析共享表空间,风险极高)。
-
准备临时恢复目录将备份文件恢复到一个临时目录(而非直接覆盖目标数据库):
-
提取目标库的文件从备份目录中复制目标库的整个文件夹到临时目录:
-
恢复到目标数据库
- 停止目标 MySQL 服务,确保数据目录干净(若目标库已存在,需先删除或重命名)。
- 将临时目录中的库文件复制到 MySQL 数据目录:
cp -r /tmp/temp_restore/mydb /var/lib/mysql/
- 修复文件权限并启动 MySQL:
chown -R mysql:mysql /var/lib/mysql/mydb
service mysqld start
-
提前准备表结构需确保目标数据库中已存在该表的结构(可通过备份时的frm
文件或逻辑备份获取)。若表结构丢失,可从备份的frm
文件恢复:
-
丢弃目标表的表空间登录 MySQL,执行命令让目标表释放现有表空间:
ALTER TABLE mydb.mytable DISCARD TABLESPACE;
-
复制备份的表数据文件从备份中复制表数据文件(ibd
)到目标库目录:
cp /path/to/backup_dir/mydb/mytable.ibd /var/lib/mysql/mydb/
chown mysql:mysql /var/lib/mysql/mydb/mytable.ibd
-
导入表空间登录 MySQL,导入备份的表空间:
ALTER TABLE mydb.mytable IMPORT TABLESPACE;
-
验证数据执行SELECT
语句确认数据是否恢复正常:
SELECT * FROM mydb.mytable LIMIT 10;
-
一致性风险单表 / 单库恢复依赖备份时的一致性(已通过--apply-log
处理),但需确保恢复后与其他表 / 库的关联性(如外键)未被破坏。
-
版本与配置匹配备份与目标数据库的 MySQL 版本、InnoDB 配置(如页大小)必须一致,否则可能导致恢复失败。
-
权限问题恢复后需严格保证文件权限为mysql:mysql
,否则 MySQL 服务无法读取。
-
替代方案若频繁需要单表 / 单库恢复,建议结合逻辑备份(如mysqldump --databases 库名
或--tables 库名.表名
),操作更简单直接。
Percona XtraBackup(innobackupex)支持单独恢复单个库或表,但需满足innodb_file_per_table=1
配置,且操作步骤较逻辑备份更复杂。适合需要快速恢复(物理文件复制)的场景,实际使用中需注意一致性和权限问题,必要时结合逻辑备份作为补充。