redo log 一次数据库的无法启动

不要假装努力，结果不会陪你演戏。

正文

又是一个寂静的周六晚上，又是我偷偷学习的好时机。（嘻嘻嘻！）
可是刚想动手写写项目，打开数据库的我，发现数据库它它它又炸了。

哇，只能说用“炸裂”形容我当时的心情。

记得我上次遇到的这样的问题，我直接把数据库删了，重新又安装了一下。
虽说是bin包直接安装，不是特别麻烦。虽说重装打法大法好。

但我还是痛定思痛，还是毅然分析起了这次错误。

作为程序员，发生错误第一想到的肯定是看错误日志。
但日志在哪呢？

找到mysql服务，右键属性，找到安装目录：

打开my.ini,这是mysql的参数配置的地方，ctrl+f5查找log。

哦，原来小东西你在这丫，让我们打开它瞅瞅里面到底是什么报错。

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

其实到这，我们已经到这猜出了问题的可能性，就是这个redo log的锅。

很简单的想法，错误无非是恢复数据时出错，只要要删除记录redo log日志的ib_logfile0和ib_logfile1，使其不要去恢复数据，
mysql应该就可以重新启动。但我们还是简单分析一下。

首先先引入几个概念：

• redo log 作为重做日志，其实是数据库中持久性的体现，当我们的数据库因为某些原因宕机的情况下，可以作为物理备份回复。

• checkpoint 我们则可以理解为日志记录中的一个标记，标记这checkpoint节点之前的redolog日志已经恢复，只需对checkpoint后的重做日志进行恢复，从而缩短恢复时间。

• MySQL5.7后引入两种新的redo log 类型：

  • MLOG_FILE_NAME用于记录在checkpoint之后，所有被修改过的信息(space, filepath)
  • MLOG_CHECKPOINT用于标志MLOG_FILE_NAME的结束。

上面两种redo log类型的添加，使得在恢复的时候，只需要从checkpoint的位置往后扫描到MLOG_CHECKPOINT的位置，这样就能获取到需要恢复的space和filepath，在恢复过程中，只需要打开这些ibd文件即可，恢复的时候也不再依赖数据字典。

MLOG_CHECKPOINT是否存在，很大程度就能判定上次MySQL是否正常关机。

根据以上判断，我有理由相信，错误很有可能是异常的关机导致数据库flush redo log时出现错误。

解决方案也很简单，就是将记录redo日志的ib_logfile0和ib_logfile1强行删除即可，当然这是一种暴力做法。

---

寻求提高是我的宗旨！期待指教与讨论

阿原爱吃车厘子 | 文 【原创】

---