Innodb事务型存储引擎，通过redo，undo，double write这些特性保证数据的完整，针对硬件故障，内核bug，突然断电的事件，需要手动对Innodb进行恢复；
可以将Innodb page 损坏分为几类，data page 损坏，secondary_index page 损坏， root index 损坏,data dictionary 损坏，恢复的难度依次增加；与朋友一起恢复innodb的时候，重新认识了下innodb_force_recovery;
最初对innodb_force_recovery 的认识只是错误的停留在 它只针对无法启动的时候使用，1-6的参数，对损坏数据只在启动的时候不去检查；后来才明白启用该参数后，MySQL redo only 就是为了保证对应参数里面的值，不启用后台thread的任何检查直至设置innodb_force_recovery=0才可以，同时跟大家分享下， check table 的结果对于innodb 是不可信的（明明error log报page错误，但检测结果仍是ok） （以下内容多参考官网）
innodb_force_recovery 在使用的时候，能尽量从1-6依次递增，=3的时候，已经包括 =1 和=2的处理情况，一般 = 1-3的时候，数据的完整性相对来说还是可以保证的（除了已经损坏的部分），>=4 的时候可能造成 page处于一种相对“过时”（obsolete state）,(如果不进行重建损坏的表)，可能造成B-trees and other database structures 的损坏，>0 的时候，INSERT,UPDATE,DELETE这些操作都是禁止的，下面介绍下各个参数的具体含义：
1 (SRV_FORCE_IGNORE_CORRUPT)：
强制忽略corrupt page并自动跳过，期间可以dump table；
2 (SRV_FORCE_NO_BACKGROUND)：
在前置忽略corrupt page 的基础上（包含=1的作用），阻塞 master thread 和 任何的 purge thread 运行（有效防止在purge的时候发生MySQL crash）
3 (SRV_FORCE_NO_TRX_UNDO)：
在忽略 corrupt page，阻塞 purge thread的基础上，不进行 transaction rollback；
4 (SRV_FORCE_NO_IBUF_MERGE)：
在忽略 corrupt page，阻塞 purge thread，禁止 transaction rollback 基础上，禁止 merge insert buffer，对 table statistics 不进行更新；（这样会损坏 data file，等恢复后最好重建所有的secondary index）；
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)：
在忽略 corrupt page ,阻塞purge thread，禁止 transaction rollback，禁止merge insert buffer，停止 table statistic 的基础上，在启动 MySQL的时候，不在扫描 undo logs，对待incomplete transactions as committed；
6 (SRV_FORCE_NO_LOG_REDO)：
在以上所有的基础上，redo log 不进行前滚（roll-forward）
这里再次提醒下，对Innodb_force_recovery的赋值最好是依次递增（除非自己做过严格测试）
本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/1564235，如需转载请自行联系原作者
