MySQL强制恢复InnoDB innodb_force_recovery 详解

mysql5.7 强制 InnoDB 恢复

当数据库页面损坏时，常规做法是使用 SELECT ... INTO OUTFILE 导出数据。大多数情况下，这种方法能够获取完整数据。但如果损坏严重，SQL 语句可能直接崩溃，甚至后台操作和前滚恢复也会挂起。此时，需要启用 innodb_force_recovery 选项——强制启动存储引擎，同时阻止后台操作，从而有机会将表导出。

操作很简单：重启服务器之前，在配置文件的 [mysqld] 部分添加一行：

[mysqld]
innodb_force_recovery = 1

关于选项文件的具体用法，可参考官方文档第4.2.2.2节。

警告

务必仅在紧急情况下将 innodb_force_recovery 设置为大于 0 的值，目的是启动 InnoDB 并导出表。操作前，请确认已拥有数据库的完整备份，以防需要重建。注意，值为 4 或以上时可能永久损坏数据文件。在生产环境使用 4 或更高设置之前，务必先在单独的数据库物理副本上测试通过。强制恢复时，请从 innodb_force_recovery=1 开始，只有在必要时才逐步增加。

innodb_force_recovery 默认值为 0（正常启动，不强制恢复）。允许的非零值为 1 到 6，较大的值包含较小值的全部功能。例如，值 3 包含了值 1 和 2 的所有能力。

如果使用 innodb_force_recovery 为 3 或更小值时能够成功转储表，则相对安全——损失的只是损坏页面上的部分数据。但值为 4 或更大时需格外小心，数据文件可能永久损坏。值 6 属于极端手段，因为数据库页面会处于过时状态，进而可能给 B 树和其他结构带来更多损坏。

作为安全措施，当 innodb_force_recovery 大于 0 时，InnoDB 会禁止 INSERT、UPDATE、DELETE 操作；值为 4 或以上时，InnoDB 被设置为只读模式。

下面详细解释每个级别的作用：

1 (SRV_FORCE_IGNORE_CORRUPT)

让服务器即使检测到损坏的页面也能继续运行。尝试跳过损坏的索引记录和页面，这有助于使用 SELECT * FROM tbl_name 转储表。

2 (SRV_FORCE_NO_BACKGROUND)

阻止主线程和任何清除线程运行。如果清除操作导致意外退出，此恢复值能够阻止其发生。

3 (SRV_FORCE_NO_TRX_UNDO)

崩溃恢复后不运行事务回滚。

4 (SRV_FORCE_NO_IBUF_MERGE)

防止插入缓冲区合并操作——如果合并会导致崩溃，则避免执行。同时不计算表统计信息。此值可能永久损坏数据文件。使用此值后，建议删除并重新创建所有二级索引。将 InnoDB 设为只读。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

启动数据库时不查看撤消日志，甚至将不完整的事务视为已提交。此值可能永久损坏数据文件。将 InnoDB 设为只读。

6 (SRV_FORCE_NO_LOG_REDO)

不执行与恢复相关的重做日志前滚。此值可能永久损坏数据文件。数据库页面会处于过时状态，进而可能给 B 树和其他数据结构带来更多损坏。将 InnoDB 设为只读。

可以使用 SELECT 从表中转储数据。当 innodb_force_recovery 值为 3 或更小时，可以使用 DROP 或 CREATE 表。在 MySQL 5.7.17 及之前版本，大于 3 的值也支持 DROP TABLE；从 5.7.18 开始，innodb_force_recovery 大于 4 时不允许使用 DROP TABLE。

如果知道某个表导致回滚时意外退出，可以尝试删除该表。如果遇到因批量导入失败导致的失控回滚（例如 ALTER TABLE），可以终止 mysqld 进程，设置 innodb_force_recovery=3 在不回滚的情况下启动数据库，然后 DROP 掉那个引发失控回滚的表。

如果表数据损坏导致无法转储整个表内容，可以尝试使用带 ORDER BY primary_key DESC 子句的查询——它可能能够导出损坏部分之后的数据。

如果启动 InnoDB 时需要很高的 innodb_force_recovery 值，说明可能存在损坏的数据结构，这可能导致复杂查询（包含 WHERE、ORDER BY 等子句）失败。这种情况下，可能只能运行最基本的 SELECT * FROM t 查询。