必须开启innodb_file_per_table,否则xtrabackup无法对单表做物理级分离备份;因该参数关闭时所有innodb表共用ibdata1系统表空间,xtrabackup无法识别并提取单表.ibd文件。

必须开启 innodb_file_per_table,否则 xtrabackup 无法对单表做物理级分离备份。
为什么部分表备份失败?常见报错和前置条件
执行 xtrabackup --tables 后发现备份目录里有空数据库子目录、或目标表根本没生成 .ibd 文件,大概率是以下原因:
-
innodb_file_per_table未启用:MySQL 启动时该参数为OFF,所有 InnoDB 表共用系统表空间ibdata1,xtrabackup无法识别并单独提取某张表的物理文件 - 表不是 InnoDB 引擎:MyISAM 或 Memory 表不支持
--tables过滤;可通过SHOW CREATE TABLE tbl\G确认ENGINE=InnoDB - 路径权限问题:
--target-dir目录需有写权限,且不能与 MySQLdatadir混用(避免覆盖) - MySQL 版本与 XtraBackup 不匹配:例如 MySQL 8.0.33+ 需搭配 Percona XtraBackup 8.0.33+,否则 prepare 阶段会报
Unknown redo log format
--tables 和 --tables-file 的实际区别
两者都用于指定要备份的表,但解析逻辑和适用场景不同:
MySQL 9.6.0是面向Linux平台的2026年创新版本,核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层,确保所有数据变更均被完整记录至Binlog,彻底解决了CDC(变更数据捕获)与主从复制中的数据不一致难题。此外,该版本引入container_aware启动选项以原生适配容器环境,并对审计日志进行了组件化重构,为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
--tables="^test[.]user$":正则匹配,必须写全db.table格式,.要转义,^和$推荐加上防止误匹配(如test.users_log会被^test[.]user错误包含) -
--tables-file=/tmp/tables.txt:按行读取纯文本,每行一个db.table,不支持通配或正则;适合备份几十上百张表,避免命令行过长或 shell 解析错误 - 注意优先级:
--tables-exclude>--tables,比如同时指定--tables="test.*" --tables-exclude="test\.log_.*",就能排除所有日志表
备份后必须加 --export 才能恢复单表
普通全量备份用 --prepare 即可,但部分备份必须显式加 --export,否则恢复时 ALTER TABLE ... IMPORT TABLESPACE 会报错 Tablespace is not encrypted and encryption mode is not NONE 或直接拒绝导入:
- prepare 阶段:
xtrabackup --prepare --export --target-dir=/backup/partial/ - 这一步会在每个表目录下生成
.cfg元数据文件(含表结构校验信息),没有它,IMPORT TABLESPACE会因校验失败而中止 - 切勿省略
--export—— 即使ls /backup/partial/test/看起来有user.ibd,没user.cfg就等于没准备好
恢复时最容易漏掉的三件事
把 .ibd 和 .cfg 拷过去只是第一步,真正让数据“活”起来还得做三件事:
- 目标库必须先建好同名空表(结构完全一致):用
mysqldump -u root -p --no-data test user > schema.sql导出再导入,不能靠CREATE TABLE LIKE,因为后者不复制COMMENT、COLUMN_FORMAT等细节 - 执行
ALTER TABLE test.user DISCARD TABLESPACE前,务必SET FOREIGN_KEY_CHECKS = 0,否则外键约束会阻止剥离操作 - 拷贝后的文件属主必须和 MySQL 进程一致(通常是
mysql:mysql),chown mysql:mysql *.ibd *.cfg缺一不可;否则启动时报Operating system error number 13
最麻烦的不是步骤多,而是 .cfg 文件缺失、属主错误、外键检查未关闭这三处问题往往不报明确错误,只表现为导入后查不到数据或表状态为 CRASHED。










