MySQL InnoDB强制恢复参数innodb_force_recovery详解

MySQL 5.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 查询。