今天一来公司,开发人员就对我说mysql无法启动起来了,一问才知道他对测试服务器上的服务都执行了重启,当时心里那个气啊,想给他124,你说你要重启服务也要问问我啊,现在整出问题来了,就知道来找我了.气归气,问题还是要解决.先检查了下服务器的磁盘空间,发现没有满,再检查了下mysql配置,也没有问题,最后看了下mysql日志,才终于找到问题,如图
 

 

  原来是有个表有问题,找到开发问了下,这个表是他才备份的,还不能删,服务器上的数据是今天最新的,还没有备份,真是日个狗了,好吧,那只能根据日志里的提示先修改innodb_force_recovery了.

  ps:

  innodb_force_recovery影响整个InnoDB存储引擎的恢复状况.默认为0,表示当需要恢复时执行所有的恢复操作.当不能进行有效的恢复操作时,mysql有可能无法启动,并记录下错误日志.innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响.当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的.

 

  1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页.

  2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash.

  3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作.

  4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作.

  5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交.

  6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作.

 

操作如下:

在my.cnf中添加了以下两个参数:

innodb_force_recovery=6

innodb_purge_thread=0

 

然后重启mysql

service mysqld restart

 

重启好了之后,立即对数据库做逻辑导出,然后将innodb_force_recovery设置为0,innodb_purge_thread=1,重建数据库.这样mysql的问题就解决了,最后把mysql的定时备份也改成早上备一次和晚上备一次了.