如何使用innodb_force_recovery解决MySQL服务器崩溃无法重启的问题

背景
一位创业的朋友，由于磁盘阵列损坏，导致电脑死机。当他重新启动MySQL服务时，发生以下错误：

InnoDB：从.ibd文件中读取表空间信息...

InnoDB：正在恢复来自 doublewrite 的可能半写入数据页

InnoDB：缓冲区...

InnoDB：进行恢复：扫描到日志序列号 9120034833< br/>

150125 16:12:51 InnoDB：开始向数据库应用一批日志记录...

InnoDB：进度百分比：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 15012516:12:51 [错误] mysqld 收到信号 11 ；

这可能是因为您遇到了错误。也有可能此二进制文件

或其链接的库之一已损坏、构建不正确、

或配置错误。此错误也可能是由硬件故障引起的。

要报告此错误，请参阅 http://kb.askmonty.org/en/reporting-bugs

我们将尽力收集一些信息，希望有助于诊断问题，但由于我们已经崩溃了，

肯定有问题，并且可能会失败。

服务器版本：5.5.37-MariaDB-log

key_buffer_size=268435456

read_buffer_size=1048576

max_used_connections=0

max_threads=1002

thread_count=0

mysqld 可能会使用最多

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2332093 K 字节内存

41 希望如此。

第二d分析
主要关注mysqld gets signal 11的问题，从日志内容分析，本机数据库崩溃，导致日志文件损坏。重启后无法正常恢复，更不能提供正常的对外服务。

三种解决办法
由于日志已经损坏，这里采用了非常规手段。首先，修改innodb_force_recovery参数，使mysqld跳过恢复步骤，启动mysqld，并保存数据。导出并重建数据库。
innodb_force_recovery可以设置为1-6，较大的数字包括之前所有数字的影响。
1. (SRV_FORCE_IGNORE_CORRUPT)：忽略检测到的损坏页面。
2. (SRV_FORCE_NO_BACKGROUND)：阻止主线程运行。如果主线程需要执行完全清除操作，就会导致崩溃。
3. (SRV_FORCE_NO_TRX_UNDO)：不执行事务回滚操作。
4. (SRV_FORCE_NO_IBUF_MERGE)：不执行插入缓冲区的合并操作。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN)：在不检查重做日志的情况下，InnoDB存储引擎会将未提交的事务视为已提交。
6. (SRV_FORCE_NO_LOG_REDO)：不执行前滚操作。
注意
a 当参数值大于0时，可以对对象进行选择、创建、删除操作但不允许对表进行插入、更新或删除等操作。
b 当innodb_purge_threads和innodb_force_recovery设置在一起时，会出现循环现象：

< / p>

150125 17:07:42 InnoDB: 等待后台线程启动

150125 17:07:43 InnoDB: 等待后台线程启动

150125 17:07:44 InnoDB：等待后台线程启动

150125 17:07:45 InnoDB：等待后台线程启动art

150125 17:07:46 InnoDB：等待后台线程启动

150125 17:07:47 InnoDB：等待后台要启动的线程

修改my.cnf中以下两个参数
innodb_force_recovery=6
innodb_purge_thread=0

重启MySQL

150125 17:10:47 [注意]崩溃恢复完成。< br/>

150125 17:10:47 [注意] 在 IP: '0.0.0.0' 上创建服务器套接字。

150125 17:10:47 [注意] 事件调度程序：已加载 0 个事件

150125 17:10:47 [注意] /vdata/webserver/mysql/bin/mysqld：准备连接。

版本：'5.5.37-MariaDB-log'套接字：'/tmp/mysql.sock'端口：3306源码分发

立即对数据库进行逻辑导出，完成后设置innodb_force_recovery为0，innodb_purge_thread=1，然后重建数据库。
另外，在MySQL 5.5版本及之前，当innodb_purge_threads =1且innodb_force_recovery >1，就会出现上面提到的循环警告问题（=1，没问题），
原因：
MySQL源码中显示，当innodb_purge_threads和innodb_force_recovery一起设置时，会出现循环

while (srv_shutdown_state == SRV_SHUTDOWN_NONE) {

if (srv_thread_has_reserved_slot(SRV_MASTER) == ULINT_UNDEFINED

|| (srv_n_purge_threads == 1

&& srv_thread_has_reserved_slot(SRV_WORKER)

== ULINT_UNDEFINED) ) {

ut_print_timestamp （标准错误）；

fprintf(stderr, " InnoDB: 等待后台线程启动\n");

os_thread_sleep(1000000);

} else {

  中断；

}

}

所以当需要设置innodb_force_recovery>1时，需要关闭innodb_purge_threads并设置为 0（默认）。

四总结
MySQL崩溃或者MySQL数据库服务器崩溃会导致各种问题，su主备服务器之间ch as error >1594（5.6版本开启crash-safe，可以避免error 1594的问题最大程度，以后会写一个新的5.6特性引入这个功能），错误1236，日志损坏，< strong>数据文件损坏等，本案只是其中之一。从日志中仔细查找。相关错误信息可以逐步解决。

如何使用innodb_force_recovery解决MySQL服务器崩溃无法重启问题的答案就分享在这里。希望以上内容能够对大家有所帮助。如果您还有很多疑问，不妨解锁一下，您可以关注行业资讯频道，了解更多相关知识。