mysql中innodb_force_recovery参数分析

1.问题描述

今天线上运行的mysql崩溃了。
查看错误日志，如下：

---------------------------------------- -- ------------ 161108 11:36:45 mysqld_safe 使用 /usr/local/mysql/var 中的数据库启动 mysqld 守护进程 2017-08-15 11:36:46 0 [警告] TIMESTAMP不推荐使用隐式 DEFAULT 值。请使用 --explicit_defaults_for_timestamp 服务器选项（有关更多详细信息，请参阅文档）。 2017-08-15 11:36:46 5497 [注意] 插件“FEDERATED”已禁用。 2017-08-15 11:36: 46 7f11c48e1720 InnoDB：警告：不推荐使用 innodb_additional_mem_pool_size 。此选项可能会在未来版本中连同操作一起删除innodb_use_sys_malloc 和 InnoDB 的内部内存分配器。2017-08-15 11:36:46 5497 [Note] InnoDB: 使用原子来引用计数缓冲池页2017-08-15 11 :36:46 5497 [Note] InnoDB: The InnoDB内存堆被禁用2017-08-15 11:36:46 5497 [注意] InnoDB：互斥锁和rw_locks使用GCC原子内置2017-08-15 11:36:46 5497 [注意] InnoDB：不使用内存屏障2017-08- 15 11:36:46 5497 [注意] InnoDB：压缩表使用 zlib 1.2.32017-08-15 11:36:46 5497 [注意] InnoDB：使用 CPU crc32 指令2017-08-15 11 :36:46 5497 [注意] InnoDB: 正在初始化缓冲池，大小 = 16.0M2017-08-15 11:36:46 5497 [注意] InnoDB: 缓冲池已完成初始化InnoDB: 磁盘上的数据库页损坏或失败InnoDB: 第5页的文件读取。InnoDB: 您可以必须从备份中恢复。2017-08-15 11:36:46 7f11c48e1720 InnoDB：ASCII 和十六进制页面转储（16384 字节）：len 16384；十六进制 7478d0780000000500000000000000000000 00000f271f4d00070000000000000000000000000000000001b40000000000000000000200f2000000000000006000000000000002d000000000000002 e00000000000002f0000000000000030000000000 (省略许多类似的代码) InnoDB: End of page dump2017 -08-15 11 :36:46 7f11c48e1720 InnoDB：未压缩的页面，在field1 1954074744中存储校验和，为field1计算校验和：crc32 993334256，innodb 2046145943，无3735928559，已存储field2 中的校验和 1139795846，计算出的 field2 校验和：crc32 993334256，innodb 160661 3742，无 3735928559，页 LSN 0 254222157，页末尾 LSN 的低 4 字节 254221236，页号（如果已存储到页）5，空间 id （如果使用 >= MySQL-4.1.1 创建并已存储） 0InnoDB：页面可能是事务系统 pageInnoDB：磁盘上的数据库页面损坏或失败InnoDB：第 5 页的文件读取 .InnoDB：您可能必须从备份中恢复。InnoDB ：也有可能您的操作InnoDB：系统已损坏其自己的文件缓存InnoDB：并且重新启动计算机会删除InnoDB：错误。InnoDB：如果损坏的页面是index pageInnoDB: 您还可以尝试通过转储、删除和重新导入 ingInnoDB: 损坏的表来修复损坏的InnoDB:。您可以使用 CHECKInnoDB: TABLE 扫描表是否损坏。InnoDB: 另请参阅 http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: 关于强制恢复 .InnoDB: 结束由于数据库页面损坏而进行处理。2017-08-15 11:36:46 7f11c48e1720 InnoDB：线程 139714288817952 infile buf0buf.cc 第 4201InnoDB 行中断言失败：我们故意生成内存陷阱。InnoDB：向 http 提交详细的错误报告： //bugs.mysql.com.InnoDB: 如果重复断言失败或崩溃，即使是在 mysqld 启动后立即出现 InnoDB: ，也可能是 InnoDB: InnoDB 表空间损坏。请参考InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.03:36:46 UTC - mysqld got signal 6 ；这可能是因为你遇到了一个错误。也有可能这个二进制文件或一个 o如果它所链接的库已损坏、构建不正确或配置错误。这个错误也可能是由硬件故障引起的。我们将尽力收集一些信息，希望有助于诊断问题，但由于我们已经崩溃了，肯定有问题，这可能会失败。key_buffer_size= 16777216read_buffer_size=262144max_used_connections=0max_threads =1000thread_count=0connection_count=0mysqld 可能最多可以使用 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 798063 K byte s 的内存希望没问题；如果不是，则减少方程中的一些变量。线程指针：0x0 尝试回溯。您可以使用以下信息来找出 mysqld 死掉的位置。如果此后您没有看到任何消息，则出现了严重错误... stack_bottom = 0 thread_stack 0x40000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8e64b 5] /usr/local/mysql/bin/mysqld( handle_fatal_signal+0x41b)[0x652fbb] /lib64/libpthread.so.0(+0xf7e0)[0x7f11c44c77e0] /lib64/libc.so.6(gsignal+0x35)[0x7f11c315d625] / lib64/libc.so.6(abort+0x175)[0x7f11c315ee05] /usr/local/mysql/bin /mysqld[0xa585c5] /usr/local/mysql/bin/mysqld[0xa6c7b4] /usr/local/mysql/bin/mysqld[0xa6cbc7] /usr/local/mysql/bin/mysqld[0xa5bce2] /usr/local/mysql /bin/mysqld[0xa1e2ba] /usr/local/mysql/bin/mysqld[0xa0bf60] /usr/local/mysql/ bin/mysqld[0x95a427] /usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x58f788 ] /usr/local/mysql/bin/mysqld[0x6e4a36] /usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0xb3e)[0x6e826e] /usr/local/mysql/bin/mysqld[0x582d85] /usr/local/ mysql/bin /mysqld(_Z11mysqld_mainiPPc+0x4d8)[0x587d18] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f11c3149d5d] /usr/local/mysql/bin/mysqld[0x57a019] 手册页位于 http:// dev.mys ql .com/doc/mysql/en/crashing.html 包含的信息可以帮助您找出导致崩溃的原因。 161108 11:36:46 mysqld_safe mysqld 来自 pid 文件 /usr/local/mysql/var/VM_241_49_centos.pid 结束-------------------------------------------------------- ------ ---------------------------- 

2.问题分析

从日志中可以看出innodb引擎有问题。日志提示您前往http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html查看强制恢复方式。找到mysql配置文件my.cnf中的[mysqld]字段，添加innodb_force_recovery=1：

[mysqld]innodb_force_recovery = 1

如果innodb_force_recovery = 1没有生效，可以尝试数字2-6
然后重启mysql，重启成功。然后使用mysqldump或者pma导出数据，进行修复操作等。修复完成后，注释掉该参数，恢复为默认值0。
配置文件参数：innodb_force_recovery
innodb_force_recovery影响整个InnoDB存储引擎的恢复状态。默认值为 0，这意味着当需要恢复时，将执行所有恢复操作（即，验证数据页/清除撤消/插入缓冲区合并/回滚和前进）。当无法执行有效的恢复操作时，mysql可能无法启动并记录错误。 log;
innodb_force_recovery可以设置为1-6，较大的数字包括之前所有数字的影响。当参数值大于0时，可以对表进行select、create、drop操作，但不允许进行insert、update、delete等操作。

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)：不检查重做日志g、InnoDB存储引擎会将未提交的事务视为已提交。

6(SRV_FORCE_NO_LOG_REDO)：不执行前滚操作。

3.分析方案

一般修复方法参考：

第一种方法

建立新表：
create table demo_bak #与原来的表结构相同，只是INNODB改为MYISAM。
插入数据
insert into demo_bak select * from demo;
删除原表：
drop table demo;
注释掉innodb_force_recovery并重启。
重命名：
rename table demo_bak to demo;
最后改回存储引擎：
alter table demo engine = innodb

第二一种方法

另一种方法是使用mysqldump导出表，然后将其导入回InnoDB表中。两种方法的结果是相同的。
备份导出（包括结构和数据）：
mysqldump -uroot -p123 test > test.sql
恢复方法一：
use test;
source test.sql
恢复方法2（系统命令行）：
mysql -uroot -p123 test < test.sql;
注意，CHECK TABLE命令在InnoDB数据库中基本没用。

第三种方法

1.配置my.cnf

配置innodb_force_recovery=1或2-6个数字，重启MySQL

2.导出数据脚本

mysqldump -uroot -p123 test > test.sql
导出SQL脚本。或者使用 Navicat 将所有数据库/表导入到其他服务器上的数据库中。
注意：这里的数据必须备份成功。然后删除原数据库中的数据。

3.删除ib_logfile0、ib_logfile1、ibdata1

备份MySQL数据目录下的ib_logfile0、ib_logfile1、ibdata1三个文件，然后删除这三个文件

3. />

4.配置my.cnf

删除my.cnf中innodb_force_recovery = 1或2-6这行配置或者配置为innodb_force_recovery = 0，并重启MySQL服务

5。将数据导入MySQL数据库

mysql -uroot -p123 test < test.sql;或者使用Navicat将备份的数据导入数据库。
该方法需要注意的问题：
1、ib_logfile0、ib_logfile1、ibdata1这三个文件必须先备份，然后再删除；
2、一定要确认原始数据是导出成功 3.当数据导出成功，原数据库中的数据被删除后，如果提示无法删除，可以在命令行进入MySQL数据目录，手动删除该文件夹相关数据库或数据库文件夹下的数据表文件。 ，前提是数据必须导出或备份成功。

感谢您的阅读。以上就是《mysql中innodb_force_recovery参数分析》的内容。经过文章的学习，相信大家都熟悉了mysq中innodb_force_recovery参数的分析湖我们对问题有了更深入的认识，具体用法还需要通过实践来验证。在此，小编将为大家推送更多相关知识点的文章，欢迎关注！