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，依次尝试重启。