innodb_force_recovery是唯一能绕过崩溃校验抢出数据的救命参数，需从1级开始逐级尝试，启动成功后立即导出数据并删除该参数重启，否则将永久只读。
MySQL崩溃后无法启动，十有八九卡在 InnoDB crash recovery 阶段——这不是配置写错了，而是 InnoDB 检测到上一次 shutdown 非正常（断电、kill -9、磁盘故障等），且当前环境不满足自动恢复条件。直接删文件或硬重启只会让数据更糟。
看到 “InnoDB: Database page corruption” 或 “mysqld got signal 11” 就该停手
这类日志不是提示你“换个配置重试”，而是明确告诉你：InnoDB 在尝试前滚（log redo）或回滚（trx undo）时出错了。此时强行重复执行 mysqld --initialize 或清空 /var/lib/mysql 可能导致元数据彻底丢失。
- 先确认错误日志位置：
/var/log/mysql/error.log或/var/lib/mysql/hostname.err，用sudo tail -n 50 hostname.err快速定位最后一段报错 - 常见触发点：虚拟机快照回滚后系统时间跳变、
ib_logfile*被旧版本残留、磁盘空间满导致 redo log 写入中断 - 别急着改
my.cnf——先检查datadir目录权限是否为mysql:mysql，且ibdata1、ib_logfile0文件存在但大小异常（如只有几 KB）
只用 innodb_force_recovery=1 启动，别一上来就设成 4
innodb_force_recovery 不是“越大力越有效”，它是按层级递进的破坏性开关。从 1 开始试，能导出数据就立刻停，不要贪高值。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
-
innodb_force_recovery = 1：跳过损坏页检测，多数情况下足够让SELECT和mysqldump跑通；若失败再试 2，依此类推 - 设为 4 及以上会禁用 undo log 扫描和 redo 前滚，InnoDB 自动进入只读模式，且可能永久损坏二级索引——除非你已确认备份无效且业务停摆
- 修改后必须重启服务：
sudo systemctl restart mysql，而不是 reload；启动成功后立即验证：mysql -uroot -e "SHOW DATABASES;"
mysqldump 失败？换 SELECT … INTO OUTFILE 绕过锁和事务
当 innodb_force_recovery ≥ 4 时，mysqldump 会因禁止 INSERT/UPDATE 报错退出。这时直接连 MySQL 执行导出更可靠。
- 确保目标路径 MySQL 进程有写权限，例如：
SELECT * FROM mytable INTO OUTFILE '/tmp/mytable.csv' FIELDS TERMINATED BY ','; - 注意：
secure_file_priv可能限制导出目录，查它：SELECT @@secure_file_priv;，只能导到该路径下 - 大表分批导：加
LIMIT和OFFSET，或按主键范围切片，避免内存溢出或超时 - 导完立刻停服务，别继续写入——此时任何 DML 都可能加剧损坏
恢复后必须删掉 innodb_force_recovery 行，否则永远只读
很多人导完数据就以为万事大吉，结果下次重启发现所有写操作都报错。这是因为 innodb_force_recovery > 0 时，InnoDB 显式拒绝任何变更操作，且这个状态不会自动清除。
- 编辑
/etc/mysql/my.cnf，找到[mysqld]下的innodb_force_recovery行，整行删除或注释掉（加#） - 删掉
/var/lib/mysql/ib_logfile0、ib_logfile1（InnoDB 会自动重建），但保留ibdata1（除非你确定要重建整个表空间） - 重启前务必确认：
sudo systemctl status mysql显示 active (running)，且mysql -e "SELECT 1;"返回 1
真正危险的不是崩溃本身，而是崩溃后盲目清空 data 目录、跳过日志校验、或在未验证备份有效性前就设 innodb_force_recovery=6——这些操作会让“可恢复”变成“不可逆丢失”。
