参数innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况

参数innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。该值默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效恢复时，如数据页发生了corruption，MySQL数据库可能会宕机，并把错误写入错误日志中。

但是，在某些情况下，我们可能并不需要执行完整的恢复操作，我们自己知道如何进行恢复。比如正在对一个表执行alter table操作，这时意外发生了，数据库重启时会对InnoDB表执行回滚操作。对于一个大表，这需要很长时间，甚至可能是几个小时。这时我们可以自行进行恢复，例如可以把表删除，从备份中重新将数据导入表中，这些操作的速度可能要远远快于回滚操作。

innodb_force_recovery还可以设置为6个非零值：1～6。大的数字包含了前面所有小数字的影响，具体情况如下。

• 1（SRV_FORCE_IGNORE_CORRUPT）：忽略检查到的corrupt页。
• 2（SRV_FORCE_NO_BACKGROUND）：阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
• 3（SRV_FORCE_NO_TRX_UNDO）：不执行事务回滚操作。
• 4（SRV_FORCE_NO_IBUF_MERGE）：不执行插入缓冲的合并操作。
• 5（SRV_FORCE_NO_UNDO_LOG_SCAN）：不查看撤销日志（Undo Log），InnoDB存储引擎会将未提交的事务视为已提交。
• 6（SRV_FORCE_NO_LOG_REDO）：不执行前滚的操作。

需要注意的是，当设置参数innodb_force_recovery大于0后，可以对表进行select、create、drop操作，但insert、update或者delete这类操作是不允许的。

模拟故障

我们来做个实验，模拟故障的发生。在第一会话中，对一张接近1 000W行的InnoDB存储引擎表执行更新操作，但是完成后不要马上提交：

start transaction;

update Profile set password='';

--start transaction语句开启了事务，同时防止了自动提交的发生，update操作则会产生大量的回滚日志。这时，我们人为地kill掉MySQL数据库服务器。

ps-ef|grep mysqld

kill-9 pid

通过kill命令，我们人为地模拟了一次数据库宕机故障，当MySQL数据库下次启动时会对update的这个事务执行回滚操作，而这些信息都会记录在错误日志文件中，默认后缀名为err。如果查看错误日志文件，可得到如下结果：

090922 13：40：20 InnoDB：Started；log sequence number 6 2530474615
InnoDB：Starting in background the rollback of uncommitted transactions
090922 13：40：20 InnoDB：Rolling back trx with id 0 5281035，8867280 rows to undo
InnoDB：Progress in percents：1090922 13：40：20
090922 13：40：20[Note]/usr/local/mysql/bin/mysqld：ready for connections.
Version：'5.0.45-log'socket：'/tmp/mysql.sock'port：3306 MySQL Community
Server（GPL）
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
InnoDB：Rolling back of trx id 0 5281035 completed
090922 13：49：21 InnoDB：Rollback of non-prepared transactions completed

可以看到，如果采用默认的策略，即把innodb_force_recovery设为0，InnoDB会在每次启动后对发生问题的表执行恢复操作，通过错误日志文件，可知这次回滚操作需要回滚8 867 280行记录，总共耗时约9分多钟。

我们做再做一次同样的测试，只不过在启动MySQL数据库前将参数innodb_force_recovery设为3，然后观察InnoDB存储引擎是否还会执行回滚操作，查看错误日志文件，可看到：

090922 14：26：23 InnoDB：Started；log sequence number 7 2253251193
InnoDB：！innodb_force_recovery is set to 3！
090922 14：26：23[Note]/usr/local/mysql/bin/mysqld：ready for connections.
Version：'5.0.45-log'socket：'/tmp/mysql.sock'port：3306 MySQL Community
Server（GPL）

这里出现了“！”，InnoDB警告你已经将innodb_force_recovery设置为3，不会进行undo的回滚操作了。因此数据库很快启动完成，但是你应该很小心当前数据库的状态，并仔细确认是否不需要回滚操作。