mysql 数据库无法启动(Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint .... and)

数据库机器的CPU和主板都换了,重新开机,发现mysql数据库无法启动!
在这里插入图片描述

Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint  .... and ...

这个问题出现在mysql 5.7之后的版本,主要的原因是mysql会在最新的checkpoint完成后都会在redo log写一个一字节的MLOG_CHECKPOINT 标记,用来标记在此之前的redo都已checkpoint完成。如果处于任何原因没有找到这个标记,那么整个redo日志文件都会被忽略。出现这个错误的话,最好是有备份进行恢复,如果没有做好备份,那只能采取非常规的启动方式,但可能造成数据丢失。
移除当前使用的redo日志文件,然后可以试着启动数据库,结果启动失败!
在这里插入图片描述这时的提示:[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496. 这样的错误,这是因为mysql writer线程按照配置的时间间隔以page为单位刷新buffer数据到磁盘,当数据刷新到磁盘的时候,新写入磁盘的page包含了较新的lsn,此时系统system表空间头的lsn并没有同步更新,通常这是检查点线程的工作。在正常的崩溃恢复中,mysql可以借助redo日志来进行前滚和回滚,但是此时redo日志已经被我们删掉了,mysql无法进行恢复操作。此时,我们设置innodb_force_recovery=3来强制启动mysql,仍然启动不成功,改成4,启动了!
再使用mysqldump导出备份,结果噩梦又降临了!
在这里插入图片描述
设置参数innodb_force_recovery=5,数据库仍然启动失败,再设置成6,启动成功!用sqldump顺利吧数据备份出来了!
再初始化数据库,把刚刚备份的数据库导入,行了!数据库恢复成功完成!
这里的关键是设置innodb_force_recovery参数,对应这个参数的说明如下:

  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):不执行前滚的操作。
姚远ACE CSDN认证博客专家 ACE 华为云 MVP
Oracle ACE,华为云 MVP,Oracle10g,12c OCM; MySQL 5.6,5.7,8.0 OCP;CCNA; EMC Certified; IBM P Certified; RHCE; SQLServer 764; DB2 Certified; TOEIC 890;获得过两次国家部级科技进步奖;发明过两项计算机专利。微信:yaoyuanace 邮箱:yaoyuanace(at)qq.com
已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页