必须用--apply-log-only串接中间增量，最后一次才去掉；否则LSN不连续导致恢复失败。因--prepare默认前滚+回滚，回滚后备份固化不可再合并增量，--apply-log-only仅前滚、保持“开放”状态以接受后续增量。
必须用 --apply-log-only 串接中间增量，最后一次才去掉它；漏加、多加或加错顺序，xtrabackup_checkpoints 里的 LSN 就对不上，恢复直接失败。
为什么 prepare 增量时要反复用 --apply-log-only
因为 xtrabackup --prepare 默认会做两件事：前滚（replay）已提交事务 + 回滚（rollback）未提交事务。一旦回滚完成，备份集就“固化”成可启动状态，不能再合并后续增量——它已经失去了继续接受变更的“一致性窗口”。--apply-log-only 的作用就是只做前滚、跳过回滚，把备份集保持在“开放”状态。所以：全量准备不用它；第一次增量合并必须加；第二次、第三次……只要不是最后一次，都得加。
合并三次备份（全量 + inc1 + inc2）的正确命令顺序
假设路径为：/backup/full、/backup/inc1、/backup/inc2，且三者都来自同一 MySQL 8.0 实例、使用 xtrabackup8.0 生成：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先准备全量：
xtrabackup --prepare --target-dir=/backup/full - 再合并第一次增量（关键：带
--apply-log-only）：xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc1 - 最后合并第二次增量（关键：不带
--apply-log-only）：xtrabackup --prepare --target-dir=/backup/full --incremental-dir=/backup/inc2
注意：--incremental-dir 指向的是增量备份目录本身（不是其中的子目录），且该目录下必须存在有效的 xtrabackup_checkpoints 文件——这是校验 LSN 连续性的唯一依据。
常见失败现象和排查点
执行 --prepare 报错 LSN mismatch 或 Invalid from_lsn，基本就这几种情况：
- 用了错误版本的
xtrabackup（比如 MySQL 8.0 用了xtrabackup-2.4或8.4+） -
--incremental-dir指向的目录被手动修改过，或xtrabackup_checkpoints文件丢失/损坏 - 中间某次增量没成功写完（比如磁盘满、权限不足），但目录空壳还在，
to_lsn和下一次的from_lsn自然接不上 - 误把
--apply-log-only加在了最后一次合并上，导致最终备份集仍处于“未回滚”状态，无法直接启动
真正麻烦的不是命令写错，而是你以为合并完了、验证也通过了，结果恢复时才发现数据页损坏——因为 LSN 校验是在 prepare 阶段做的，但某些损坏可能只在实际启动 MySQL 时暴露。所以，哪怕脚本里写了 completed OK!，也建议用 mysql --datadir=/backup/full 尝试初始化一次（不启动服务，只校验文件结构）。
