innodb_force_recovery 恢复（慎重）

前言

近期，测试环境出现了一次MySQL数据库不断自动重启的问题，导致的原因是强行kill -9 杀掉数据库进程导致，报错信息如下：

2019-07-24T01:14:53.769512Z 0 [Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check.
2019-07-24T01:14:53.769516Z 0 [Note] Beginning of list of non-natively partitioned tables
01:14:53 UTC - 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=33554432
read_buffer_size=8388608
max_used_connections=0
max_threads=501
thread_count=4
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4478400 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f486900e000
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f4846172820 thread_stack 0x80000
/usr/local/mysql5.7/bin/mysqld(my_print_stacktrace+0x2c)[0xed481c]
/usr/local/mysql5.7/bin/mysqld(handle_fatal_signal+0x461)[0x7a15a1]
/lib64/libpthread.so.0(+0xf7e0)[0x7f498697c7e0]
/usr/local/mysql5.7/bin/mysqld(_ZN12ha_federated7rnd_posEPhS0_+0x2f)[0x12bcc3f]
/usr/local/mysql5.7/bin/mysqld(_ZN7handler10ha_rnd_posEPhS0_+0x172)[0x804a12]

/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event24do_index_scan_and_updateEPK14Relay_log_info+0x1e3)[0xe50e23]
/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0x716)[0xe50196]
/usr/local/mysql5.7/bin/mysqld(_ZN9Log_event11apply_eventEP14Relay_log_info+0x6e)[0xe48fde]

/usr/local/mysql5.7/bin/mysqld(_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x1f0)[0xe8d6f0]
/usr/local/mysql5.7/bin/mysqld(handle_slave_sql+0x163d)[0xe9a0fd]

/usr/local/mysql5.7/bin/mysqld(pfs_spawn_thread+0x1b4)[0x1209414]
/lib64/libpthread.so.0(+0x7aa1)[0x7f4986974aa1]
/lib64/libc.so.6(clone+0x6d)[0x7f4984c6bc4d]

 

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 2
Status: NOT_KILLED

You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

1. 初探过程

之前出现过类似的情况时，是因为内存不足，因日志中也有对应的提示：

1 2 3 4 5 6 7 8 9

key_buffer_size=33554432 read_buffer_size=8388608 max_used_connections=0 max_threads=501 thread_count=4 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4478400 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.

此测试环境物理内存确实不大，且剩余内存也不足，而且是作为另一个测试环境的从库，内存分配的也少。

之前一些环境也出现过类似的情况，通过调整参数及释放内存的等处理后可以正常启动，于是尝试着关闭一些临时程序并调整MySQL上述几个参数的值，如：

1 2	[mysqld] max_connections = 50

然后重新启动MySQL，结果依旧不断重启。

初步处理未果。

 

2.   添加innodb_force_recovery 解决不断重启

在配置文件my.cnf添加innodb_force_recovery 先处理不断重启的问题

1 2	[mysqld] innodb_force_recovery = 4

添加后，再次启动MySQL，此时不再出现反复重启。

查看数据库日志，有提示 [Note] InnoDB: !!! innodb_force_recovery is set to 4 !!!如下：

因为此时可以打开数据库，于是尝试启动从库，但是此时报错，提示Table 'mysql.slave_relay_log_info' is read only.

此时再看错误日志，如下

因此，本次启动时，innodb_force_recovery 设置为 4，在MySQL 5.6.15 以后，当 innodb_force_recovery 的值大于等于 4 的时候，InnoDB 表处于只读模式，因启动复制时需要将信息写入表中，所以此时报错。

注： 因设置为1-3 时，依旧未生效，因此我在处理时设置的为4（4 以上的值可能永久导致数据文件损坏。如果生产环境出现类似问题务必先拷贝一份测试，在测试通过后再在生产环境处理）。此时可以将所有数据dump出，之后再恢复即可。

3.  innodb_force_recovery 参数

innodb_force_recovery 可以设置为 1-6，大的值包含前面所有小于它的值的影响。

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的 corrupt 页。尽管检测到了损坏的 page 仍强制服务运行。一般设置为该值即可，然后 dump 出库表进行重建。

2 (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行，如主线程需要执行 full purge 操作，会导致 crash。 阻止 master thread 和任何 purge thread 运行。若 crash 发生在 purge 环节则使用该值。

3 (SRV_FORCE_NO_TRX_UNDO): 不执行事务回滚操作。

4 (SRV_FORCE_NO_IBUF_MERGE): 不执行插入缓冲的合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值，则将来要删除和重建辅助索引。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB 存储引擎会将未提交的事务视为已提交。此时 InnoDB 甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。

6 (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作。恢复时不做 redo log roll-forward。使数据库页处于废止状态，继而可能引起 B 树或者其他数据库结构更多的损坏。

注意：

1. 为了安全，当设置参数值大于 0 后，可以对表进行 select, create, drop 操作,但 insert, update 或者 delete 这类操作是不允许的。
2. MySQL 5.6.15 以后，当 innodb_force_recovery 的值大于等于 4 的时候，InnoDB 表处于只读模式。
3. 在值小于等于 3 时可以通过 select 来 dump 表，可以 drop 或者 create 表。
4. MySQL 5.6.27 后大于 3 的值也支持 DROP TABLE； 如果事先知道哪个表导致了崩溃则可 drop 掉这个表。
5. 如果碰到了由失败的大规模导入或大量 ALTER TABLE 操作引起的 runaway rollback，则可 kill 掉 mysqld 线程然后设置 innodb_force_recovery = 3 使数据库重启后不进行 rollback。然后删除导致 runaway rollback 的表； 如果表内的数据损坏导致不能 dump 整个表内容。那么附带 order by primary_key desc 从句的查询或许能够 dump 出损坏部分之后的部分数据；

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对脚本之家的支持。

 

 

Oh My Gold 改了些配置，啥都没了!都没了!没了!了!

我仔细询问，原来是她因为某些原因将某库的物理文件夹改名后，发现数据库找不到了。于是又将名称改回来。结果仍然找不到。这让她觉得数据可能被损坏了，于是赶忙来找我修复。

修复过程

我们数据库用的版本是 MySQL5.7 ,放置在Linux服务器上，在my.cnf 配置了数据库物理文件的存放地址。存放于 data 文件夹下。

表的存储引擎全部使用 InnoDB，data 目录的文件依次如下

用数据库名命名的文件夹，文件夹内存放的 .ibd ,.frm 文件依次是数据库表数据文件和表结构文件

ibdata1 (存放InnoDB表元数据、undo logs、the change buffer, and the doublewrite buffer) 文件

ib_logfile0 ，ib_logfile1 事务日志

 

这个时候我首先想到的是我本机用Navicat备份过一个文件，立刻打开Navicat尝试还原备份，然而日志全是 Err错误，显示表存在，但是我们是看不到的。这时候我就打算删除该库，直接使用备份恢复，然而数据库删除仍然报错。我只得去备份了一下物理文件然后删除。删除后再使用Navicat还原

经过一番操作，数据库文件是回来了。但是我电脑上的备份文件他不是实时的，虽然恢复了数据库，但仍然丢失了部分数据，我心有不甘。于是我想了一个“妙计”： 我把刚才备份的物理文件里面的 .frm .ibd 文件替换到新创建的物理文件夹中。这样狸猫换太子之后，我岂不是就拥有了最完整的数据？

说干就干，一通 cp -rf 过后，成功替换掉原来的文件。打开Navicat连接没有问题，心里窃喜。就在这时，陆续有同事反应数据库连不上了，我的天呐。什么鬼？我打开MoBa查看linux 进程，发现Mysql 服务已经宕掉了。我尝试重启，报出如下错误：

 

查看Mysql 错误日志：

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.

Attempting to collect some information that could help diagnose the problem.

As this is a crash and something is definitely wrong, the information

collection process might fail.

经过上网查询，说是可以通过在 my.cnf 添加如下的配置来强制启动数据库官方文档对于该配置的解释 ，同类问题的回答

[mysqld]

innodb_force_recovery = 1

1 (SRV_FORCE_IGNORE_CORRUPT)

使服务器即使检测到损坏的页也可以运行 。尝试跳过损坏的索引记录和页，这有助于转储表。

2 (SRV_FORCE_NO_BACKGROUND)

阻止主线程和任何清除线程运行。如果在清除操作期间发生崩溃，则此恢复值可防止崩溃。

3 (SRV_FORCE_NO_TRX_UNDO)

崩溃恢复后 不运行事务回滚。

4 (SRV_FORCE_NO_IBUF_MERGE)

防止插入缓冲区合并操作。如果它们会导致崩溃，请不要这样做。不计算表 统计信息。此值可能会永久损坏数据文件。使用此值后，准备删除并重新创建所有二级索引。设置 InnoDB为只读。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

启动数据库时 不查看撤消日志： InnoDB甚至将未完成的事务也视为已提交。此值可能会永久损坏数据文件。设置InnoDB为只读。

6 (SRV_FORCE_NO_LOG_REDO)

不进行与恢复有关的重做日志前回滚。此值可能会永久损坏数据文件。使数据库页面处于过时状态，这又可能导致B树和其他数据库结构遭受更多破坏。设置 InnoDB为只读。

官方文档特别说明：当级别 >= 4 时，可能会对数据库文件造成不可挽回的破坏。我尝试从1 开始逐步修改该值启动。直到 6 才正常启动。启动后，只能执行查询语句，增删改都不行。于是我将数据库文件全部备份后。关闭数据库，删除原来的 数据库物理文件、ibdata1 文件、ib_logfile0 文件。之后将 innodb_force_recovery 值还原为默认值0。重新恢复了数据库文件。解除了此次危机。

启发

定时备份数据库！即使是测试库。测试库可以调的时间间隔长一点

在不懂的情况下不要自作聪明乱动物理文件！

innodb_force_recovery=6表示mysql数据库已经有比较严重的损坏，就算把数据dump出来也不能保证dump出来的数据是没有问题的

最后建议选择第一个解决办法修改innodb_force_recovery的方法来恢复mysql，而不要选择第二个办法