不要假装努力，结果不会陪你演戏。
正文
又是一个寂静的周六晚上，又是我偷偷学习的好时机。（嘻嘻嘻！）
可是刚想动手写写项目，打开数据库的我，发现数据库它它它又炸了。
image
image
哇，只能说用“炸裂”形容我当时的心情。
记得我上次遇到的这样的问题，我直接把数据库删了，重新又安装了一下。
虽说是bin包直接安装，不是特别麻烦。虽说重装打法大法好。但我还是痛定思痛，还是毅然分析起了这次错误。
image
作为程序员，发生错误第一想到的肯定是看错误日志。
但日志在哪呢？
找到mysql服务，右键属性，找到安装目录：
image
image
打开my.ini,这是mysql的参数配置的地方，ctrl+f5查找log。
image
哦，原来小东西你在这丫，让我们打开它瞅瞅里面到底是什么报错。
image
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强行删除即可，当然这是一种暴力做法。
寻求提高是我的宗旨！期待指教与讨论
阿原爱吃车厘子 | 文 【原创】
网友评论