mysql宕机日志查询_mysql宕机分析(事务日志损坏)

mysql宕机分析(事务日志损坏)

一、情景概述.

1.服务器配置

a)  1CPU 8核

b)  16G内存

c)  2T 硬盘

2. Mysql 在一个普通硬盘中长时间处于大量写的状态(长时间大概是几个月).

3. 突然有一个天Mysql无故宕机,无法在启动.

一、故障分析

1. 查看错误日志.

1363663578_4302.jpg

a). 从上面日志来看,本以为是内存不够,mysql的有些参数过大.

所以,关闭所用大量内存的程序,调整配置参数,包括innodb_buffer_pool_size

b). 在此基础上重新启动mysql服务.依然启动失败.继续查看错误日志.

上面的错误,依旧会显示在错误日志里面.但是慢慢看来,还会有别的错误.

1363663653_2987.jpg

从上面日志可以看出,innodb的表空间根本无法找到事务日志里面的LSN点

可见日志已经被损坏(暂不知为什么就被损坏).

c).根据日志的提醒,可以看到一个网站,进入这个网站可以看到这样一个参数

1363663749_4334.jpg

这个参数的含义如下:

1363663802_9030.jpg

在my.cnf文件中加入innodb_force_recovery = 4

再次启动mysql,发现是完全可以启动的.

现在只有加入这个参数,mysql才能正常的启动和关闭.但这个参数太危险了在以后的操作中可能会丢失数据.

所以需要把现在库里面的数据全部dump出来.重新还原到一个新的实例中.

PS:如果你试图想重新初始化一个新的事务日志.让mysql正常运行几乎是不能的.

因为,在表空间里面早就记录了那个错误的LSN点.不管不怎么初始化,只要找不到这个LSN点,就不会启动成功

你可能感兴趣的:(mysql宕机日志查询)