xtrabackup恢复必须严格按lsn顺序合并：先对全量执行--apply-log --redo-only，再依次对各增量执行--apply-log --redo-only，最后对全量执行--apply-log（无--redo-only）完成一致性校验。
合并全量和增量备份不是“把文件拷一起”就能用，关键在于按 LSN 顺序重放日志，让 InnoDB 数据页达到最终一致状态。跳过 --redo-only 或顺序错乱，恢复出来的库大概率无法启动或数据损坏。
必须先对全量备份执行 --apply-log --redo-only
全量备份只是文件快照，InnoDB 页可能处于中间状态（比如部分事务已提交、部分未刷盘）。这一步会读取备份目录里的 xtrabackup_logfile，把所有已提交但未落盘的 redo 日志应用进去，但不回滚未提交事务——因为后续增量还要往里追加变更。
- 命令示例：
xtrabackup --apply-log --redo-only --target-dir=/backup/full_20260801 - 必须加
--redo-only：否则会直接回滚未提交事务，导致后续增量无法合并 - 执行后检查
xtrabackup_checkpoints文件，确认to_lsn值已更新 - 如果漏掉这步，直接合并增量会报错
LSN mismatch或卡在 apply 阶段
增量备份要按生成顺序逐个 --apply-log --redo-only
每个增量备份都基于前一次备份的 to_lsn，所以合并必须严格按时间/LSN 递增顺序。第二次增量不能跳过第一次直接合并到全量上，否则缺失中间变更，数据页会校验失败。
- 第一次增量合并：
xtrabackup --apply-log --redo-only --target-dir=/backup/full_20260801 --incremental-dir=/backup/inc_20260802 - 第二次增量合并：
xtrabackup --apply-log --redo-only --target-dir=/backup/full_20260801 --incremental-dir=/backup/inc_20260803 - 每次合并后，
/backup/full_20260801目录内容会被修改，xtrabackup_checkpoints中的to_lsn也会更新 - 误把
--incremental-dir指向一个不含有效xtrabackup_checkpoints的目录，xtrabackup 会静默失败，生成无效备份
最后一个增量合并完，去掉 --redo-only 再跑一次 --apply-log
这一步才是真正“收尾”：它会回滚所有未提交事务，并确保所有数据页 checksum 一致。此时目录才可作为恢复源直接复制到 datadir 启动 MySQL。
- 命令示例：
xtrabackup --apply-log --target-dir=/backup/full_20260801（注意没有--redo-only） - 如果这里还留着
--redo-only，MySQL 启动时会报错InnoDB: Database page corruption - 执行完检查
xtrabackup_checkpoints，backup_type应为full-prepared，且to_lsn和last_lsn相等 - 这步不可省略，也不能提前做——必须等所有增量都合并完毕
最容易被忽略的是 --redo-only 的开关时机：它只在中间合并阶段存在，最终一致性必须靠一次无参数的 --apply-log 完成。LSN 链一旦断开或顺序错位，就只能从最近一次全量重新开始，增量链本身不具备容错性。
