共计 1389 个字符，预计需要花费 4 分钟才能阅读完成。
作者：姚远
专一于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。当初鼎甲科技任参谋，为共事和客户提供数据库培训和技术支持服务。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
故障形容
MySQL 数据库服务器的 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 log 文件都会被疏忽。呈现这个谬误的话，最好是有备份进行复原，如果没有做好备份，那只能采取非常规的启动形式，但可能造成数据失落。
故障解决
移除以后应用的 redo log 文件，而后能够试着启动数据库，后果启动失败！
提醒：
[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 log 来进行前滚和回滚，然而此时 redo log 曾经被咱们删掉了，MySQL 无奈进行复原操作。此时，咱们设置 innodb_force_recovery=3 来强制启动 MySQL，依然启动不胜利，改成 4 后启动了！
再应用 mysqldump 导出备份，后果噩梦又来临了！MySQL 又 crash 了。
提醒：
InnDB: Failed to find tablespace for table……
设置参数 innodb_force_recovery=5，数据库依然启动失败，再设置成 6，启动胜利！用 sqldump 顺利把数据备份进去了！
再初始化数据库，把刚刚备份的数据库导入，数据库复原胜利实现！
参数阐明
这里的要害是设置 innodb_force_recovery 参数，对应这个参数的阐明如下：
- SRV_FORCE_IGNORE_CORRUPT：疏忽查看到的 corrupt 页；
- SRV_FORCE_NO_BACKGROUND：阻止主线程的运行，如主线程须要执行 full purge 操作，会导致 crash；
- SRV_FORCE_NO_TRX_UNDO：不执行事务回滚操作；
- SRV_FORCE_NO_IBUF_MERGE：不执行插入缓冲的合并操作；
- SRV_FORCE_NO_UNDO_LOG_SCAN：不查看重做日志，InnoDB 存储引擎会将未提交的事务视为已提交；
- SRV_FORCE_NO_LOG_REDO：不执行前滚的操作。