有时候我们的站点服务器会因为各类问题出现重启或者崩溃，甚至断电的情况，如果正在读取大量数据的情况下，重启后有可能出现数据库的Innodb存储引擎损坏的情况，这时候我们怎么解决呢？这里搬主题就分享一下解决方案。这里搬主题是基于BT宝塔面板进行介绍，建议将本文通读一遍后再根据解决方案进行处理。什么？还没安装BT宝塔面板？点击进行下载安装宝塔服务器面板，一键全能部署及管理，送你3188元礼包，点我领取问题出现的原因：正常情况下，数据库在做查询语句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的数据存储目录做个备份，备份是为了以防万一，如果有快照，尽量做个磁盘快照。打开BT宝塔面板，其中默认的数据库存储路径在 /www/server/data备份命令：cp -rp /www/server/data wwwbackupdata_20223、到MySQL的配置文件中添加面板的MySQL配置文件默认是 /etc/my.cnfinnodb_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官方给的解决方案都无法解决当前的问题，建议找专业的数据恢复公司。
THE END
