在我的环境中有一个装在VMware的RHEL上的MySQL.由于某些原因,我不得不将整个物理机硬关机,因此,造成了MySQL的Crash.

在物理机重新启动后,Linux系统起来没有问题,但是MySQL的启动却报错了.

具体内容如下:

启动服务:

可以看到,上面报错了.

看看报错信息吧:

看看错误日志中的表现:

日志内容较长,所以,没有在命令行中[cat].
详情看下面的内容吧:

关于这个问题的解法,上面的错误中已经给出提示了:
https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

需要启用参数: innodb_force_recovery

官方说明如下:

可以看到:
默认情况下,该参数是[0],表示启动的时候,不做强制修复.
而在非零的情况下,该参数的值是从[1-6]

在数据库的配置文件中启用这个参数.

该参数的设置从小往大修改,[0 –> 6].
如果当前值还不能修复,则一步步的提升该参数的值.

从上面可以看到,我的该参数在【1】的时候还是无法启动数据库,提升到【2】的时候就好了.

修改参数后的操作记录具体如下:

这个过程中的日志如下:


注意,上面只是以【innodb_forced_recovery=2】的方式将数据库启动了,并不是表示数据库被修复了。

导出数据库全库:

可以看到,MySQL的数据被全库导出了,总共【36 MB】

删除MySQL数据目录中的ib_logfile文件:

修改innodb_force_recovery参数的值,还原为默认的【0】

然后,重启MySQL数据库服务:

可以看到,服务已经启动成功了。

登录数据库看看具体的情况:

可以看到,当前已经恢复到了按照正常的方式启动。

这个过程中的日志如下:【/mysql_data/log/mysqld.log】

可以看到,虽然数据库按照Normal的方式起来了,但是还是有一些warning;
这些也是要修复的。

把前面通过mysqldump导出的文件,重新导入数据库:

因为,前面有过备份,所以,现在,先把现有的库都删掉:

可以看到,上面有两个库删除的时候有问题,在导入的时候,也是它们有问题。

停掉数据库服务,然后去数据目录删除对应的SCHEMA目录,然后再拉起数据库服务: