lsn不匹配本质是数据文件与重做日志状态脱节，表现为ibdata1中lsn大于当前重做日志最大lsn，导致innodb拒绝加载；常见原因包括未执行xtrabackup --prepare、残留旧redo日志、mysql小版本不一致；修复须严格按清空日志文件、禁用innodb_redo_log_encrypt、用同版本xtrabackup prepare、确保datadir为空且权限正确等步骤执行。
LSN不匹配的本质是数据文件和重做日志状态脱节
这不是磁盘损坏或备份失败，而是 MySQL 启动时发现 ibdata1 里记录的 LSN（Log Sequence Number）比当前重做日志能提供的最大 LSN 还大。典型错误如：[ERROR] [MY-011971] [InnoDB] Tablespace 'mysql' Page [...] log sequence number 4128108770 is in the future! Current system log sequence number 3141751615. 意味着你拷来的数据页“比日志还新”，InnoDB 拒绝加载——它没法从日志里回放那些“未来”的变更。
最常被忽略的三个触发点
恢复前没做 --prepare，或者 prepare 不完整；目标实例残留了旧版 redo 日志；备份来源和目标 MySQL 小版本不一致（比如 8.0.26 备份往 8.0.42 上恢复）。
- 直接复制
datadir文件夹跳过xtrabackup --prepare阶段，会导致重做日志未合并、LSN 未对齐——物理备份不是“复制即用” - 目标目录下残留
ib_logfile0、ib_logfile1或#innodb_redo/目录，MySQL 启动时会优先读它们，而不是信任备份里的日志状态 - 8.0.30+ 引入
innodb_redo_log_encrypt，若源库未启用但目标 my.cnf 里写了innodb_redo_log_encrypt=ON，MySQL 会尝试解密空日志，导致 LSN 校验失败
修复步骤必须按顺序执行
先清空、再准备、最后启动。中间任何一步跳过都可能让问题更隐蔽。
- 停掉 MySQL，删掉目标
datadir下所有ib_logfile*和#innodb_redo/目录（不要只删一个） - 确认
my.cnf中没有innodb_redo_log_encrypt，或显式设为OFF（哪怕源库没开） - 用和备份时**完全相同版本**的
xtrabackup执行：xtrabackup --prepare --target-dir=/path/to/backup（增量备份需先--apply-log-only再最终 prepare） - 复制前确认目标
datadir是空目录，且属主属组正确（如mysql:mysql）
小版本差异比想象中更危险
8.0.33 和 8.0.34 看似只差一个补丁号，但 redo log 格式可能有微调。官方 release note 里不会标“此版本修复 LSN 校验逻辑”，而是藏在 “InnoDB: Refactor log buffer handling” 这类描述里。生产环境跨小版本恢复前，务必查对应版本的 Percona 官方兼容性矩阵——别信“都是 8.0 就行”这种经验。
