全量恢复后启动卡在crash recovery，是因为innodb检测到磁盘上残留的redo日志（ib_logfile0/1）lsn大于数据文件头lsn，判定存在未刷盘事务，必须强制回放日志以校验一致性，即使数据已从备份恢复干净；根本原因是恢复前未清空或重建redo日志文件。
MySQL在全量恢复后启动卡在Crash Recovery，不是因为“恢复没做完”，而是InnoDB发现磁盘上残留的redo日志（ib_logfile0、ib_logfile1）与当前数据文件（ibdata1、表空间文件）状态不一致，必须强制走一遍崩溃恢复流程——哪怕你刚从备份里拷贝了干净的数据。
为什么全量恢复后还会触发Crash Recovery
全量恢复（如用mysqldump导入或直接替换.ibd文件）本身不修改InnoDB的redo日志文件。MySQL启动时，InnoDB会检查ib_logfile*中的LSN（日志序列号）是否大于数据文件头记录的LSN。只要前者更大，就判定“有未刷盘的事务”，必须回放redo、校验页、重建字典缓存——这就是你看到的“Starting crash recovery…”卡住。
- 常见于：恢复前没清空
ib_logfile*，或备份时没停库、没FLUSH LOGS - 即使你用
innodb_force_recovery=1能启动，也只是跳过部分步骤，不代表底层一致性已修复 -
SHOW ENGINE INNODB STATUS\G中LOG小节的Last checkpoint at和Log sequence number差值大，就是典型信号
如何确认是redo日志残留导致的假性崩溃恢复
别急着调innodb_force_recovery。先验证是不是日志文件“过期”了：
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 执行
mysql -u root -p -e "SELECT @@innodb_log_file_size;"，记下当前配置值 - 检查
ib_logfile*实际大小：ls -lh /var/lib/mysql/ib_logfile*，若与上一步值不一致，说明日志文件没随配置更新，极可能损坏或版本错位 - 查看错误日志末尾是否有
InnoDB: Doing recovery: scanned up to log sequence number XXX持续推进但不结束，说明正在读取大量旧日志 - 用
strings /var/lib/mysql/ib_logfile0 | head -20看开头是否有可读字符串（如innodb），全乱码大概率已损坏
安全跳过假性Crash Recovery的实操步骤
目标是让InnoDB相信“日志已清空”，从而跳过冗长恢复。这不是绕过真正损坏，而是清理掉与当前数据不匹配的残留日志：
- 确保MySQL已完全停止：
systemctl stop mysql，且ps aux | grep mysqld无残留进程 - 备份原始日志：
cp /var/lib/mysql/ib_logfile* /tmp/ib_logfile_backup_$(date +%s)/ - 删除日志文件：
rm /var/lib/mysql/ib_logfile*（注意：不是重命名，InnoDB启动时会自动重建） - 启动MySQL：
systemctl start mysql。首次启动会打印InnoDB: Creating ib_logfile0... with size XXX MB，几秒内完成，不再卡在crash recovery - 验证：
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Uptime';"，Uptime应为几十秒而非几分钟以上
哪些操作会让这个问题更难解
最容易被忽略的是“恢复后没删日志，还顺手改了innodb_log_file_size”。这时InnoDB会因日志文件大小与配置不符直接拒绝启动，报错InnoDB: Error: log file ib_logfile0 is of different size。此时不能只删日志，必须同步确保：
- 配置文件中
innodb_log_file_size与你准备重建的日志大小一致 - 删日志前确认
innodb_fast_shutdown = 0（否则关闭时不会刷脏页，重启后仍要recover） - 如果用了
innodb_force_recovery启动过，必须先导出数据，再清空日志+重建实例，不能带病运行进生产
真正麻烦的不是卡在crash recovery，而是你误以为它“只是慢”，却在日志还在回放时强行kill进程——这会让redo和数据页再次错位，下次启动卡得更久，甚至触发Database page corruption。删日志前那句cp ...不是仪式，是底线。
