数据库机器的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):不执行前滚的操作。
