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的赋值最好是依次递增（除非自己做过严格测试）

本文出自 “技术成就梦想” 博客，请务必保留此出处http://weipengfei.blog.51cto.com/1511707/1564235

Innodb恢复--innodb_force_recovery