宝塔的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，依次尝试重启。
未经允许不得转载：肥猫博客 » mysql无故关闭_宝塔的mysql老是自己关闭停止
