如何正确使用XtraBackup对MySQL 8.0做全量与增量物理备份-mysql教程-PHP中文网

全量备份必须用--backup且加--no-server-version-check，因MySQL 8.0与XtraBackup 8.x严格版本绑定（如8.0.33配8.0.33），否则报unsupported server version；定制版还常需该参数绕过校验失败。

如何正确使用xtrabackup对mysql 8.0做全量与增量物理备份

全量备份必须用 `--backup`，不能漏掉 `--no-server-version-check`

MySQL 8.0 和 XtraBackup 8.x 版本强绑定，比如 MySQL 8.0.33 必须配 XtraBackup 8.0.33，否则执行时会直接报错 unsupported server version。但即便版本对得上，某些定制版（如国产麒麟、部分云厂商MySQL RDS兼容版）仍可能因内部版本字符串不标准触发校验失败。此时 --no-server-version-check 不是“可选项”，而是让命令跑通的必要开关。

全量备份命令示例：

xtrabackup --defaults-file=/etc/my.cnf \
  --backup \
  --target-dir=/data/backup/full/$(date +%F_%H%M) \
  --parallel=4 \
  --compress \
  --compress-threads=2 \
  --no-server-version-check

--defaults-file 必须指向真实生效的 MySQL 配置文件，且其中 [client] 段要包含 user 和 password，避免密码明文暴露在命令行或进程列表里
--parallel 建议设为 CPU 核心数的 20%～50%，SSD 环境下超过 8 反而可能因 I/O 竞争拖慢整体速度
压缩虽省空间，但会增加 CPU 开销；若备份目标是高速 NAS 或对象存储，建议关掉 --compress，靠网络带宽或后端压缩更可控

增量备份依赖上一次成功备份的 `xtrabackup_checkpoints` 文件

增量不是“比对当前数据和上周日全备”，而是严格基于上一次备份目录下的 xtrabackup_checkpoints 文件里的 to_lsn 值。这个文件由上一次 --backup 自动生成，必须存在且未被手动修改。如果脚本里删了旧备份但没清理对应 checkpoint，后续增量会找不到基点，报错 Cannot find a valid backup directory。

增量备份命令示例（接在全备之后）：

xtrabackup --defaults-file=/etc/my.cnf \
  --backup \
  --incremental \
  --incremental-basedir=/data/backup/full/2026-11-03_0200 \
  --target-dir=/data/backup/inc/2026-11-04_0200 \
  --no-server-version-check

--incremental-basedir 必须是**上一次成功完成的备份目录**（可以是全量，也可以是前一个增量），不能是 prepare 过的目录，也不能是空目录
不要试图用 ls -t | head -1 自动找最新备份目录——如果某次备份中途失败，残留的空目录会把整个链搞断
生产脚本里应加校验：[[ -f "$BASEDIR/xtrabackup_checkpoints" ]] || { echo "基准备份损坏"; exit 1; }

恢复前必须按顺序 `--prepare`，且最后一个增量要用 `--redo-only`

物理备份恢复不是“拷回去就能用”。必须先做 --prepare，即应用重做日志使数据页达到一致性状态。全量 + 多个增量的场景下，顺序和参数组合极易出错：

全量备份目录：直接 xtrabackup --prepare --target-dir=/data/backup/full/...
第一个增量：加 --redo-only，并指定 --incremental-dir 指向它，同时 --target-dir 仍指向全量目录
第二个及后续增量：同样加 --redo-only，继续 merge 到全量目录
最后一个增量处理完后，再对全量目录执行一次不带 --redo-only 的 --prepare，完成回滚未提交事务

漏掉任意一次 --redo-only，或者顺序颠倒，都会导致恢复后数据库启动失败，报错 InnoDB: Database page corruption 或 Missing MLOG_CHECKPOINT。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

备份账号权限不足会导致静默失败或部分表跳过

XtraBackup 需要读取数据文件、重做日志、系统表空间，还要访问 performance_schema.log_status（MySQL 8.0.14+）获取一致性位点。仅给 SELECT 权限远远不够。

最小必要权限清单：

RELOAD（用于 FLUSH TABLES WITH READ LOCK，尽管热备中只短暂使用）
PROCESS（读取 INFORMATION_SCHEMA.PROCESSLIST 判断是否有长事务阻塞）
SUPER 或 SYSTEM_VARIABLES_ADMIN（MySQL 8.0.16+ 推荐用后者，用于设置 innodb_log_write_ahead_size 等临时变量）
REPLICATION CLIENT（获取 binlog 位置，辅助一致性判断）
LOCK TABLES（配合 FLUSH 使用）

创建账号示例：

CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'strong_pass_2026';
GRANT RELOAD, PROCESS, SYSTEM_VARIABLES_ADMIN, REPLICATION CLIENT, LOCK TABLES ON *.* TO 'bkpuser'@'localhost';

注意：SUPER 在 MySQL 8.0.16+ 已被拆分为多个细粒度权限，继续授予 SUPER 会触发警告，且某些云数据库（如阿里云RDS）根本不支持该权限。

LSN 是整个链条的隐性主线——全量记录起始 LSN，每个增量记录自己的 from/to LSN，prepare 过程本质就是按 LSN 时间线把日志“重放”一遍。任何跳过 checkpoint 校验、乱序 merge、或忽略 --redo-only 的操作，都在破坏这条时间线。它不报错，但恢复出来的数据可能已经不一致。