• ADADADADAD

    mysql中innodb_force_recovery参数分析[ mysql数据库 ]

    mysql数据库 时间:2024-11-26 22:12:44

    作者:文/会员上传

    简介:

    一、问题描述今天在线运行的一个mysql崩溃了。查看错误日志,如下:-----------------------------------------16110811:36:45mysqld_safeStartingmysqlddaemonwithdatabasesfr

    以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。

    一、问题描述

    今天在线运行的一个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数据库中基本上是没有用的。

      第三种方法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三个文件,然后将这三个文件删除

      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参数分析.docx

    将本文的Word文档下载到电脑

    推荐度:

    下载
    热门标签: mysqlinnodb