备份前须确认：1.mysqld运行且socket路径正确；2.MySQL用户具备RELOAD、LOCK TABLES、REPLICATION CLIENT权限；3.innodb_file_per_table=ON；4.启用TDE时keyring插件已加载且keyring_file_data配置妥当。

备份前必须确认的 4 个状态

Percona XtraBackup 不是“拿来就跑”的工具，它对 MySQL 实例状态敏感。备份失败往往不是命令写错，而是环境没对齐。

• mysqld 进程必须正在运行，且 socket 文件可访问（--socket=/var/lib/mysql/mysql.sock 要匹配实际路径）
• MySQL 用户需有 RELOAD、LOCK TABLES、REPLICATION CLIENT 权限，仅 SELECT 不够
• InnoDB 表空间不能启用 innodb_file_per_table=OFF（XtraBackup 8.0+ 已不支持全局表空间备份）
• 若启用了 innodb_encryption 或 TDE，必须提前配置 keyring_file_data 并确保备份时 keyring 插件已加载

xtrabackup --backup 命令的关键参数取舍

看似简单的备份命令，参数组合直接影响恢复可用性。最常被忽略的是 --target-dir 和 --no-timestamp 的配合问题。

• --target-dir 必须指定为**空目录**；若目录存在且非空，xtrabackup 默认拒绝写入（除非加 --force-non-empty-directories，但不推荐）
• --no-timestamp 要和 --target-dir 同时使用，否则会在目标路径下自动生成时间戳子目录，导致后续 --prepare 找不到预期结构
• --parallel=4 可提升备份速度，但并发数不宜超过物理 CPU 核心数；过高反而因 I/O 争抢拖慢整体耗时
• 不加 --stream=tar 时，备份是本地文件目录；加了就必须配合 --compress 和管道重定向，例如：

  xtrabackup --backup --stream=tar ./backup/ | gzip > backup.tar.gz

prepare 阶段为什么总报 “Log sequence number mismatch”

这是恢复链断裂的典型信号——--prepare 本质是回放 redo log 到数据文件，若日志不连续或被截断，就会失败。

• 单次完整备份后，必须执行 xtrabackup --prepare 才能用于恢复；只备份不 prepare 的数据目录无法启动 MySQL
• 若做了增量备份，prepare 顺序必须是：先 prepare 全备（加 --apply-log-only），再按时间顺序依次 prepare 每个增量包（也都加 --apply-log-only），最后对最后一个增量包 **去掉** --apply-log-only 执行最终 prepare
• 误删或覆盖了 xtrabackup_logfile（即使备份已完成），会导致 prepare 报错；该文件必须和备份目录一起保留

恢复到新实例时 /etc/my.cnf 的关键适配项

直接把备份数据拷过去改个 datadir 就启动？大概率失败。MySQL 启动时会校验元数据一致性。

• innodb_data_home_dir 和 innodb_data_file_path 必须与原备份环境一致；若原环境用默认值（如 ibdata1:12M:autoextend），新实例也别改
• server_id 必须修改，否则在主从场景下可能引发 GTID 冲突或复制中断
• 若原库启用了 innodb_page_size=64K，新实例的 my.cnf 中必须显式声明，否则启动时报 page size mismatch
• 恢复后首次启动建议加 --skip-grant-tables 和 --skip-networking，验证数据可读后再开放连接

备份本身不难，难的是让 prepare 出来的数据能真正被 mysqld 认作“合法的 InnoDB 文件”。每一步的中间产物（尤其是 xtrabackup_checkpoints 和 xtrabackup_info）都得留着，它们才是恢复时唯一可信的时间戳和状态凭证。