MySQL 5.7 迁移必须用 XtraBackup 2.4.x 执行 --backup → --prepare → --copy-back 三步闭环，跳过 --prepare 会导致启动报 tablespace not found 或 checksum mismatch；全量备份需指定空目标目录，增量须链式基于上一次备份的 xtrabackup_checkpoints，恢复时须严格按序合并并正确使用 --apply-log-only。
MySQL 5.7 迁移不能靠 cp 或 rsync 直接拷贝数据目录，必须走 xtrabackup --backup → --prepare → --copy-back 三步闭环，否则启动必报 tablespace not found 或 innodb_checksum_algorithm mismatch。
全量备份命令必须带 --target-dir 且路径为空
直接运行 xtrabackup --backup 会失败，因为缺少目标路径。MySQL 5.7 必须用 Percona XtraBackup 2.4.x（XtraBackup 8.0 不兼容），且 --target-dir 指向的目录必须不存在或为空：
-
--target-dir=/backup/full_$(date +%F)是安全写法；重复使用同一目录会报错退出 - 备份前确认 MySQL 正在运行，且
xtrabackup进程有权限读取datadir（如/var/lib/mysql）和写入目标路径 - 若用非 root 用户执行，需在
my.cnf的[client]段落中配置user和password，否则报错Access denied for user ''@'localhost' - 生产环境建议加
--throttle=100限速，避免 IO 打满影响业务
--prepare 是迁移成败的关键中间步骤
备份出来的目录不是“即插即用”的物理副本，而是处于崩溃恢复前状态：redo 日志未应用、ibdata1 和各 .ibd 文件不一致、系统库元数据是只读快照。跳过 --prepare 直接 --copy-back，MySQL 5.7 启动时必然 abort：
- 必须执行：
xtrabackup --prepare --target-dir=/backup/full_2026-09-01 - 这一步让所有
.ibd可被 InnoDB 正常加载，校验值补全，innodb_checksum_algorithm=crc32才能通过 - 如果目标机 MySQL 版本与源不一致（如 5.7.21 → 5.7.39），
--prepare后还需运行mysql_upgrade -u root -p，否则performance_schema表字段可能缺失
增量备份只能链式追加，不能反复基于全量
增量不是“相对于全量的差”，而是“相对于上一次任意成功备份（全量或增量）的 LSN 差”。误用会导致恢复时数据缺失且静默失效：
- 第一次增量：
xtrabackup --backup --target-dir=/backup/inc_2026-09-02 --incremental-basedir=/backup/full_2026-09-01 - 第二次增量：
--incremental-basedir必须指向/backup/inc_2026-09-02，不是再指回全量目录 -
--incremental-basedir路径下必须存在有效的xtrabackup_checkpoints文件——XtraBackup 不校验路径是否存在，只打开该文件读to_lsn；指错就静默损坏 - 每次增量后，检查
cat /backup/inc_2026-09-02/xtrabackup_checkpoints | grep to_lsn，确保它等于下一次的from_lsn
恢复时必须按序合并，--redo-only 不能漏
恢复不是把某个备份目录直接拷进 datadir。InnoDB 需要重放日志才能保证一致性，而增量日志必须严格按顺序合并进全量：
- 先对全量目录做首次
--apply-log --redo-only：xtrabackup --prepare --apply-log-only --target-dir=/backup/full_2026-09-01 - 再逐个合并增量（顺序不能错！）：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full_2026-09-01 --incremental-dir=/backup/inc_2026-09-02 - 最后一个增量合并完，去掉
--apply-log-only再跑一次：xtrabackup --prepare --target-dir=/backup/full_2026-09-01，才算最终一致性状态 - 漏掉某次增量，或顺序颠倒，
--apply-log可能卡住或报LSN mismatch错误
最易被忽略的是 xtrabackup_checkpoints 文件的完整性——它一旦丢失或被手动修改，整个增量链就断了，而 XtraBackup 不会主动校验其逻辑有效性，只当它是权威输入。
