这篇文章主要讲解了“mysql中innodb_force_recovery参数分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“mysql中innodb_force_recovery参数分析”吧！

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

-----------------------------------------16110811:36:45mysqld_safeStartingmysqlddaemonwithdatabasesfrom/usr/local/mysql/var2017-08-1511:36:460[Warning]TIMESTAMPwithimplicitDEFAULTvalueisdeprecated.Pleaseuse--explicit_defaults_for_timestampserveroption(seedocumentationformoredetails).2017-08-1511:36:465497[Note]Plugin'FEDERATED'isdisabled.2017-08-1511:36:467f11c48e1720InnoDB:Warning:Usinginnodb_additional_mem_pool_sizeisDEPRECATED.Thisoptionmayberemovedinfuturereleases,togetherwiththeoptioninnodb_use_sys_mallocandwiththeInnoDB'sinternalmemoryallocator.2017-08-1511:36:465497[Note]InnoDB:Usingatomicstorefcountbufferpoolpages2017-08-1511:36:465497[Note]InnoDB:TheInnoDBmemoryheapisdisabled2017-08-1511:36:465497[Note]InnoDB:Mutexesandrw_locksuseGCCatomicbuiltins2017-08-1511:36:465497[Note]InnoDB:Memorybarrierisnotused2017-08-1511:36:465497[Note]InnoDB:Compressedtablesusezlib1.2.32017-08-1511:36:465497[Note]InnoDB:UsingCPUcrc32instructions2017-08-1511:36:465497[Note]InnoDB:Initializingbufferpool,size=16.0M2017-08-1511:36:465497[Note]InnoDB:CompletedinitializationofbufferpoolInnoDB:DatabasepagecorruptionondiskorafailedInnoDB:filereadofpage5.InnoDB:Youmayhavetorecoverfromabackup.2017-08-1511:36:467f11c48e1720InnoDB:Pagedumpinasciiandhex(16384bytes):len16384;hex7478d078000000050000000000000000000000000f271f4d000700000000000000000000000000000000001b4000000000000000000200f20000000000000006000000000000002d000000000000002e000000000000002f0000000000000030000000000（省略很多类似代码）InnoDB:Endofpagedump2017-08-1511:36:467f11c48e1720InnoDB:uncompressedpage,storedchecksuminfield11954074744,calculatedchecksumsforfield1:crc32993334256,innodb2046145943,none3735928559,storedchecksuminfield21139795846,calculatedchecksumsforfield2:crc32993334256,innodb1606613742,none3735928559,pageLSN0254222157,low4bytesofLSNatpageend254221236,pagenumber(ifstoredtopagealready)5,spaceid(ifcreatedwith>=MySQL-4.1.1andstoredalready)0InnoDB:PagemaybeatransactionsystempageInnoDB:DatabasepagecorruptionondiskorafailedInnoDB:filereadofpage5.InnoDB:Youmayhavetorecoverfromabackup.InnoDB:ItisalsopossiblethatyouroperatingInnoDB:systemhascorrupteditsownfilecacheInnoDB:andrebootingyourcomputerremovestheInnoDB:error.InnoDB:IfthecorruptpageisanindexpageInnoDB:youcanalsotrytofixthecorruptionInnoDB:bydumping,dropping,andreimportingInnoDB:thecorrupttable.YoucanuseCHECKInnoDB:TABLEtoscanyourtableforcorruption.InnoDB:Seealsohttp://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB:aboutforcingrecovery.InnoDB:Endingprocessingbecauseofacorruptdatabasepage.2017-08-1511:36:467f11c48e1720InnoDB:Assertionfailureinthread139714288817952infilebuf0buf.ccline4201InnoDB:Weintentionallygenerateamemorytrap.InnoDB:Submitadetailedbugreporttohttp://bugs.mysql.com.InnoDB:Ifyougetrepeatedassertionfailuresorcrashes,evenInnoDB:immediatelyafterthemysqldstartup,theremaybeInnoDB:corruptionintheInnoDBtablespace.PleaserefertoInnoDB:http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB:aboutforcingrecovery.03:36:46UTC-mysqldgotsignal6;Thiscouldbebecauseyouhitabug.Itisalsopossiblethatthisbinaryoroneofthelibrariesitwaslinkedagainstiscorrupt,improperlybuilt,ormisconfigured.Thiserrorcanalsobecausedbymalfunctioninghardware.Wewilltryourbesttoscrapeupsomeinfothatwillhopefullyhelpdiagnosetheproblem,butsincewehavealreadycrashed,somethingisdefinitelywrongandthismayfail.key_buffer_size=16777216read_buffer_size=262144max_used_connections=0max_threads=1000thread_count=0connection_count=0Itispossiblethatmysqldcoulduseuptokey_buffer_size+(read_buffer_size+sort_buffer_size)*max_threads=798063KbytesofmemoryHopethat'sok;ifnot,decreasesomevariablesintheequation.Threadpointer:0x0Attemptingbacktrace.Youcanusethefollowinginformationtofindoutwheremysqlddied.Ifyouseenomessagesafterthis,somethingwentterriblywrong...stack_bottom=0thread_stack0x40000/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8e64b5]/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]Themanualpageathttp://dev.mysql.com/doc/mysql/en/crashing.htmlcontainsinformationthatshouldhelpyoufindoutwhatiscausingthecrash.16110811:36:46mysqld_safemysqldfrompidfile/usr/local/mysql/var/VM_241_49_centos.pidended------------------------------------------------------------------------------二、问题分析

从日志中可以看出是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，表示当需要恢复时执行所有的恢复操作（即校验数据页/purge undo/insert buffer merge/rolling back&forward），当不能进行有效的恢复操作时，mysql有可能无法启动，并记录错误日志；
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。

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):不执行前滚的操作。

一般修复方法参考：

建立一张新表：
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
还原方法1：
use test;
source test.sql
还原方法2（系统命令行）：
mysql -uroot -p123 test < test.sql;
注意，CHECK TABLE命令在InnoDB数据库中基本上是没有用的。

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

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

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

将my.cnf中innodb_force_recovery = 1或2——6几个数字这行配置删除或者配置为innodb_force_recovery = 0，重启MySQL服务

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

感谢各位的阅读，以上就是“mysql中innodb_force_recovery参数分析”的内容了，经过本文的学习后，相信大家对mysql中innodb_force_recovery参数分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！