共计 3558 个字符，预计需要花费 9 分钟才能阅读完成。
行业资讯
数据库
MySQL 数据库
怎么利用 innodb_force_recovery 解决 MySQL 服务器 crash 无法重启问题
怎么利用 innodb_force_recovery 解决 MySQL 服务器 crash 无法重启问题，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
一 背景
某一创业的朋友的主机因为磁盘阵列损坏机器 crash, 重启 MySQL 服务时 报如下错误:
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer…
InnoDB: Doing recovery: scanned up to log sequence number 9120034833
150125 16:12:51 InnoDB: Starting an apply batch of log records to the database…
InnoDB: Progress in percents: 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 150125 16:12:51 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 5.5.37-MariaDB-log
key_buffer_size=268435456
read_buffer_size=1048576
max_used_connections=0
max_threads=1002
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2332093 K bytes of memory
41 Hope that.
二 分析
主要关注 mysqld got signal 11 的问题, 从日志内容分析来看, 数据库在机器 crash 导致日志文件损坏, 重启之后无法正常恢复, 更无法正常对外提供服务。
三 解决
因为日志已经损坏，这里采用非常规手段, 首先修改 innodb_force_recovery 参数，使 mysqld 跳过恢复步骤，将 mysqld 启动, 将数据导出来然后重建数据库。
innodb_force_recovery 可以设置为 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): 不查看重做日志，InnoDB 存储引擎会将未提交的事务视为已提交。
6. (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作。
注意
a 当设置参数值大于 0 后，可以对表进行 select,create,drop 操作, 但 insert,update 或者 delete 这类操作是不允许的。
b 当 innodb_purge_threads 和 innodb_force_recovery 一起设置会出现一种 loop 现象:
150125 17:07:42 InnoDB: Waiting for the background threads to start
150125 17:07:43 InnoDB: Waiting for the background threads to start
150125 17:07:44 InnoDB: Waiting for the background threads to start
150125 17:07:45 InnoDB: Waiting for the background threads to start
150125 17:07:46 InnoDB: Waiting for the background threads to start
150125 17:07:47 InnoDB: Waiting for the background threads to start
在 my.cnf 中修改以下两个参数
innodb_force_recovery=6
innodb_purge_thread=0
重启 MySQL
150125 17:10:47 [Note] Crash recovery finished.
150125 17:10:47 [Note] Server socket created on IP: 0.0.0.0 .
150125 17:10:47 [Note] Event Scheduler: Loaded 0 events
150125 17:10:47 [Note] /vdata/webserver/mysql/bin/mysqld: ready for connections.
Version: 5.5.37-MariaDB-log socket: /tmp/mysql.sock port: 3306 Source distribution
立即对数据库做逻辑导出，完成之后将 innodb_force_recovery 设置为 0，innodb_purge_thread=1 , 然后重建数据库 。
另外 MySQL 版本 5.5 以及之前 , 当 innodb_purge_threads =1，innodb_force_recovery 1 的情况会出现上文提到的循环报 warning 问题（=1 没有问题），
原因：
MySQL 的源代码中显示 当 innodb_purge_threads 和 innodb_force_recovery 一起设置会出现 loop 循环
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(stderr);
fprintf(stderr, InnoDB: Waiting for the background threads to start\n
os_thread_sleep(1000000);
} else {
break;
}
}
所以当需要设置 innodb_force_recovery 1 的时候需要关闭 innodb_purge_threads，设置为 0（默认）。
四 小结
MySQL crash 或者 MySQL 数据库服务器 crash 会导致各种各样的问题，比如主备之间的 error 1594 (5.6 版本开启 crash-safe，会最大程度上避免 error 1594 的问题，以后会写 5.6 新特性介绍该功能 )，error 1236，日志损坏，数据文件损坏，等等，本案例只是其中的一种，细心从日志中找的相关错误提示，逐步解决即可。
关于怎么利用 innodb_force_recovery 解决 MySQL 服务器 crash 无法重启问题问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
