zoukankan      html  css  js  c++  java
  • innodb crash

     今天上午同事处理了一个innodb crash 的问题,没有备份,如何恢复?

    查看日志:

    180928  8:42:44  InnoDB: Error: page 163855 log sequence number 16703789459
    InnoDB: is in the future! Current system log sequence number 16703705148.    
    InnoDB: Your database may be corrupt or you may have copied the InnoDB
    

     

    根据提示信息 http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html分析解决办法:

    1:数据库系统快速关闭参数,innodb_fast_shutdown ,有3个值可以选择0,1,2

    0表示在innodb关闭的时候,需要purge all, merge insert buffer,flush dirty pages。这是最慢的一种关闭方式,但是restart的时候也是最快的。
    1表示在innodb关闭的时候,它不需要purge all,merge insert buffer,只需要flush dirty page,在缓冲池中的一些数据脏页会刷新到磁盘。
    2表示在innodb关闭的时候,它不需要purge all,merge insert buffer,也不进行flush dirty page,只将log buffer里面的日志刷新到日志文件log files,MySQL下次启动时,会执行恢复操作

     

    MariaDB [(none)]> show variables like '%fast%';
    +----------------------+-------+
    | Variable_name        | Value |
    +----------------------+-------+
    | innodb_fast_checksum | OFF   |
    | innodb_fast_shutdown | 1     |
    +----------------------+-------+

    不论为:0,1,2,如果存在mysql crash,其实innodb 启动过程中会利用redo log做崩溃恢复。

    接下来的操作过程是
    (1). Rollback uncompleted transitions  回滚为提交的事物
    (2). Purge all 清除无用的undo页 
    (3). Merge insert buffer 合并插入缓冲

    如果redolog丢失了该写入的部分数据。上述过程无法完成。系统无法正常启动。

    这里官方可以move redolog来启动redolog,是有前提的:前提是 干净的关闭数据库,意味着是一致性关库,而且innodb_fast_shutdown  参数是0或1,显然不能解决上面问题

    Removing redo logs to speed up recovery is not recommended, even if some data loss is acceptable. 
    Removing redo logs should only be considered after a clean shutdown, with innodb_fast_shutdown set to 0 or 1.

     接下来使用 innodb-force-recovery 参数进行恢复:在mysql的配置文件my.cnf里找到 [mysqld]字段下,添加 innodb_force_recovery=1,如果innodb_force_recovery = 1不生效,则可尝试2——6几个数字(后面解释)

    这里设置了6才能启动(why)

    然后重启mysql,强制启动成功,后续恢复

    1:使用mysqldump导出数据:

    2:清除mysql下文件,把该参数注释掉,还原默认值0。重新初始化数据库

    3:重新建库,导入数据。


    配置文件的参数: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):不执行前滚的操作。 
    • 解释下为什么6才可以启动,因为前面看到截图,丢失redo,不能前滚,所以选择6。
    • enum {
          SRV_FORCE_IGNORE_CORRUPT = 1,   /*!< let the server run even if it
                          detects a corrupt page */
          SRV_FORCE_NO_BACKGROUND = 2,    /*!< prevent the main thread from
                          running: if a crash would occur
                          in purge, this prevents it */
          SRV_FORCE_NO_TRX_UNDO = 3,  /*!< do not run trx rollback after
                          recovery */
          SRV_FORCE_NO_IBUF_MERGE = 4,    /*!< prevent also ibuf operations:
                          if they would cause a crash, better
                          not do them */
          SRV_FORCE_NO_UNDO_LOG_SCAN = 5, /*!< do not look at undo logs when
                          starting the database: InnoDB will
                          treat even incomplete transactions
                          as committed */
          SRV_FORCE_NO_LOG_REDO = 6   /*!< do not do the log roll-forward
                          in connection with recovery */
      };
      

        

  • 相关阅读:
    【2020-05-03】发掘自己内心那个原点的力量
    【2020-05-02】要适应不确定性
    【2020-05-01】人生十三信条
    【一句日历】2020年5月
    【2020-04-30】每一句话,都是自我学习
    【2020-04-29】勤奋是一种享受
    【2020-04-28】自我观念强化的实践
    【2020-04-27】自我提升的里程碑
    【2020-04-26】还在温室里的自己
    家谱树(信息学奥赛一本通 1351)
  • 原文地址:https://www.cnblogs.com/monkeybron/p/9718082.html
Copyright © 2011-2022 走看看