mysql无故关闭_宝塔的mysql老是自己关闭停止

宝塔的mysql老是自己关闭停止

最近一个安装宝塔环境的项目,mysql老是关闭停止了。连续好多次了,然后我就发现不对劲。然后去查了下日志,日志内容:

2019-12-29 11:11:00 30969 [Note] InnoDB: Highest supported file format is Barracuda.

2019-12-29 11:11:00 30969 [Note] InnoDB: The log sequence numbers 1171642114 and 1171642114 in ibdata files do not match the log sequence number 1212536715 in the ib_logfiles!

2019-12-29 11:11:00 30969 [Note] InnoDB: Database was not shutdown normally!

2019-12-29 11:11:00 30969 [Note] InnoDB: Starting crash recovery.

2019-12-29 11:11:00 30969 [Note] InnoDB: Reading tablespace information from the .ibd files...

2019-12-29 11:11:03 30969 [Note] InnoDB: Restoring possible half-written data pages

2019-12-29 11:11:03 30969 [Note] InnoDB: from the doublewrite buffer...

InnoDB: Last MySQL binlog file position 0 40168625, file name mysql-bin.000032

2019-12-29 11:11:04 30969 [Note] InnoDB: 128 rollback segment(s) are active.

2019-12-29 11:11:04 30969 [Note] InnoDB: Waiting for purge to start

2019-12-29 11:11:04 30969 [Note] InnoDB: 5.6.45 started; log sequence number 1212536715

2019-12-29 11:11:04 30969 [Note] Recovering after a crash using mysql-bin

2019-12-29 11:11:04 30969 [Note] Starting crash recovery...

2019-12-29 11:11:04 30969 [Note] Crash recovery finished.

2019-12-29 11:11:05 30969 [Note] Server hostname (bind-address): '*'; port: 3306

2019-12-29 11:11:05 30969 [Note] IPv6 is available.

2019-12-29 11:11:05 30969 [Note] - '::' resolves to '::';

2019-12-29 11:11:05 30969 [Note] Server socket created on IP: '::'.

2019-12-29 11:11:05 30969 [Note] Event Scheduler: Loaded 0 events

2019-12-29 11:11:05 30969 [Note] /www/server/mysql/bin/mysqld: ready for connections.

Version: '5.6.45-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution

分析日志后发现,数据库无法重启的原因是因为ibdata1文件 (即共享表空间) 损坏,重启后无法正常恢复。

解决办法:

需要跳过恢复步骤,修改my.cnf文件,在my.cnf中的[mysqld]中添加:

innodb_force_recovery = 6

innodb_purge_threads = 1

修改后,接着重启Mysql服务,发现可正常启动。如果还是无法启动,则就需要删除mysql数据目录下的 "ibdata1、ib_logfile*" 等文件 (删除前,提前做好备份),然后再做Mysql服务启动操作!!

######################## innodb_force_recovery参数说明 ########################

MySQL数据库当innodb表空间损坏时(如ibdata1文件损坏),尝试启动Mysql服务失败。这个时候可以使用innodb_force_recovery参数进行强制启动!!下面说下这个参数的用法:

innodb_force_recovery参数解释:

-------------------------------------------------------------------------------------------------------------

innodb_force_recovery影响整个InnoDB存储引擎的恢复状况,默认值为0,表示当需要恢复时执行所有的恢复操作!!

当不能进行有效的恢复操作时,Mysql有可能无法启动,并记录下错误日志。

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。

当该参数的数值设置大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。

innodb_force_recovery=0 表示当需要恢复时执行所有的恢复操作;

innodb_force_recovery=1 表示忽略检查到的corrupt页;

innodb_force_recovery=2 表示阻止主线程的运行,如主线程需要执行full purge操作,会导致crash;

innodb_force_recovery=3 表示不执行事务回滚操作;

innodb_force_recovery=4 表示不执行插入缓冲的合并操作;

innodb_force_recovery=5 表示不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交;

innodb_force_recovery=6 表示不执行前滚的操作,强制重启!

-------------------------------------------------------------------------------------------------------------

记一次事故:

线上Mysql环境采用一主两从模式,突然一天上午发现主从库的Mysql服务都启动失败,最后排查是Mysql共享表空间ibdata1文件损坏了。

恢复记录:

1) 在主从库的Mysql配置文件my.cnf中添加

# vim /etc/my.cnf

innodb_force_recovery=6

2) 启动mysql服务

# service mysqld start

3)如果启动成功后,再将my.cnf文件中的"innodb_force_recovery=6"配置去掉,然后再次尝试mysql服务的重启,应该OK。

在主从库出现这种情况时,如果配置文件里之前就有这个参数,则尝试将该参数值修改为0或6,依次尝试重启。

THE END