小小编
服务器断电|重启后造成InnoDB存储引擎损坏导致无法正常启动MySQL的解决方案
建议将本文通读一遍后再根据解决方案进行处理。
出现的原因：
正常情况下，数据库在做查询语句Select * From Table_Name时候，会正常返回完整的数据给用户，当在做查询的时候，或者InnoDB存储引擎后台操作意外退出或者中断，会导致InnoDB向前回滚恢复数据的时候失败，主要的错误显示如下：
错误1：
错误2：
- 2022-01-02 22:05:36 7f114f118720 InnoDB: Error: page 251 log sequence number 135630634
- InnoDB: is in the future! Current system log sequence number 43744780.
- InnoDB: Your database may be corrupt or you may have copied the InnoDB
- InnoDB: tablespace but not the InnoDB log files. See
- InnoDB: http://dev.mysql.com/doc/refman/ … nnodb-recovery.html
- InnoDB: for more information.
- 2022-01-02 22:05:36 7f114f118720 InnoDB: Error: page 530 log sequence number 43789292
- InnoDB: is in the future! Current system log sequence number 43744780.
- InnoDB: Your database may be corrupt or you may have copied the InnoDB
- InnoDB: tablespace but not the InnoDB log files. See
- InnoDB: http://dev.mysql.com/doc/refman/ … nnodb-recovery.html
- InnoDB: for more information.
- 2022-01-02 22:05:36 7f114f118720 InnoDB: Error: page 252 log sequence number 151634539
- InnoDB: is in the future! Current system log sequence number 43744780.
- InnoDB: Your database may be corrupt or you may have copied the InnoDB
- InnoDB: tablespace but not the InnoDB log files. See
- InnoDB: http://dev.mysql.com/doc/refman/ … nnodb-recovery.html
- InnoDB: for more information.
- 2022-01-02 22:05:36 7f114f118720 InnoDB: Error: page 517 log sequence number 151634539
- InnoDB: is in the future! Current system log sequence number 43744780.
- InnoDB: Your database may be corrupt or you may have copied the InnoDB
- InnoDB: tablespace but not the InnoDB log files. See
- InnoDB: http://dev.mysql.com/doc/refman/ … nnodb-recovery.html
- InnoDB: for more information.
复制代码
对此错误，解决方案如下：
1、首先确定下错误是否和上述的错误信息是否一致，然后关闭Web服务（Apache或者Nginx）。
2、把MySQL的数据存储目录做个备份，备份是为了以防万一，如果有快照，尽量做个磁盘快照。
面板中默认的数据库存储路径在
/www/server/data
备份命令：
- \cp -rp /www/server/data \www\backup\data_2022
复制代码
3、到MySQL的配置文件中添加
面板的MySQL配置文件默认是 /etc/my.cnf
- innodb_force_recovery
复制代码
设置完成后重启数据库
innodb_force_recovery默认是非0 的整数，一共有1–6 6个参数值，下面是参数解读：
- 1 (srv_force_ignore_corrupt)
- 启动MySQL服务，即使它检测到一个损坏的页面。试图使SELECT * FROM tbl_name跳过损坏的索引记录和页面，这有助于转储表。
- 2 (srv_force_no_background)
- 防止主线程和任何清除线程的运行。如果在清除操作中会发生意外退出，这个恢复值可以防止它退出。
- 3 (srv_force_no_trx_undo)
- 在崩溃恢复后不运行事务回滚。
- 4 (srv_force_no_ibuf_merge)
- 防止插入缓冲区的合并操作。如果它们会导致崩溃，则不做这些操作。不计算表的统计数据。这个值会永久地破坏数据文件。在使用这个值之后，要准备放弃并重新创建所有的二级索引。将InnoDB设置为只读。
- 5 (srv_force_no_undo_log_scan)
- 在启动数据库时不查看撤销日志。InnoDB甚至将不完整的事务视为已提交。这个值会永久地破坏数据文件。将InnoDB设置为只读。
- 6 (srv_force_no_log_redo)
- 不做与恢复有关的重做日志滚动。这个值会永久地破坏数据文件。使数据库页面处于过时的状态，这反过来又可能给B树和其他数据库结构带来更多的损坏。将InnoDB设置为只读。
- 你可以从表中SELECT来转储它们。如果innodb_force_recovery的值为3或更小，你可以DROP或CREATE表。当innodb_force_recovery值大于3时，也支持DROP TABLE。如果innodb_force_recovery的值大于4，则不允许DROP TABLE。
- 如果你知道一个给定的表在回滚时导致意外退出，你可以放弃它。如果你遇到由失败的大规模导入或ALTER TABLE引起的失控回滚，你可以杀死mysqld进程并将innodb_force_recovery设置为3以使数据库在没有回滚的情况下恢复，然后DROP引起失控回滚的表。
- 如果表数据中的损坏使你不能转储整个表的内容，带有ORDER BY primary_key DESC子句的查询可能能够转储表中损坏部分之后的部分。
- 如果需要一个高的innodb_force_recovery值来启动InnoDB，可能会有损坏的数据结构，导致复杂的查询（包含WHERE、ORDER BY或其他子句的查询）失败。在这种情况下，你可能只能运行基本的SELECT * FROM t查询。
复制代码
4、上面的6个参数值，后面的包含前面的功能，如参数3，包含了参数1 和参数2 的所有功能，这里的参数总有一个可以将数据库启动，注意：若有无法启动的情况，请将二进制日志清除（没有做备份的请勿执行此命令）：
- rm -f /www/server/data/ib_*
- rm -f /www/server/data/mysql-bin*
复制代码
然后重启MySQL。
5、重启数据库后，下面进行备份数据库：
一般情况下在面板做计划任务的比较多：
添加好后记得点击执行按钮，数据库如果较大的话，备份可能需要点时间，
也可以在数据库管理界面，点击备份按钮进行备份
6、当备份完成后将现在的数据库服务停止，记得备份当数据库名和对应的密码，然后卸载当前的数据库
7、重新安装MySQL后，新建数据库，密码指定之前复制的
8、等到还原成功后，重启Nginx或者Apache，观察网站是否正常。
结语：服务器之所以被称为服务器，就是其强大的稳定能力和持续服务能力，除非必要，不要重启服务器，平时多做数据的备份，出现问题时不慌！
如果您在使用面板的时候遇到问题，可以到论坛发帖求助。
FAQ：
①、为什么要关闭Web服务（Nginx或者Apache）？
答：此时MySQL已经无法正常提供服务，如果一直开着Nginx或者Apache，会导致外部访问一直在请求数据库，生成大量的错误日志，如果磁盘容量小，则会很快出现磁盘空间不足
②、为什么要做快照或者备份？
答：在处理数据的时候，可能会因特殊情况导致无法启动MySQL，如果没有备份，或者快照，会导致现有的“数据”损坏，对数据库造成二次损毁
③、为什么要复制数据库名和对应的密码？
答：节省时间，面板上新建数据库会重新生成一个随机密码，当前如果您的网站中的数据库信息和运行的数据库的信息不一致，也是无法进行连接的，在重新创建数据库的时候直接以之前的数据库名和密码进行创建数据库，不用在到网站配置文件中修改信息，这样启动Web服务后就可以直接使用
④、如果我都尝试了，数据库还是无法启动怎么办？
答：MySQL官方给的解决方案都无法解决当前的问题，建议找专业的数据恢复公司。
参考MySQL官方解决方案的链接：
https://dev.mysql.com/doc/refman … nnodb-recovery.html
https://dev.mysql.com/doc/refman … nnodb-recovery.html
https://dev.mysql.com/doc/refman … nnodb-recovery.html
