正在阅读:

记一次解决MySQL经常停止运行的问题

img201411221428360219_info300X300.png

问题背景

在多个月之前,也就是服务器刚刚搭建的时候,标题中的MySQL问题就出现了,很是奇怪,博客过一段时间就毫无征兆的挂掉了,提示连接数据库失败,然后重新启动一下MySQL服务就又可以正常运行了。但是这个问题总是像莫名其妙的发生,时不时的给我来一点小惊喜,小意外,我每次重启MySQL服务之后就又可以正常运行了,所以就没去怎么解决这个问题。但是最近真的是忍无可忍了,决定解决了它。

先说一下我的服务器情况:

服务器:CentOS 6.8

MySQL版本:5.5

找到MySQL错误日志文件位置

解决问题当然是要看问题出在哪里,好在MySQL有自己的错误日志可以供我们分析。那么错误日志在那里呢? 我们可以用下面的方法找到这个文件的位置:

第一步:登录MySQL终端;

第二步运行下面的命令来查找错误日志的文件位置;


1
mysql> show variables like '%log_error%';

输出如下:


1
2
3
4
5
6
+---------------+----------------------------------------+
| Variable_name | Value                                  |
+---------------+----------------------------------------+
| log_error     | /www/wdlinux/mysql-5.5.27/var/kTWO.err |
+---------------+----------------------------------------+
1 row in set (0.03 sec)

从结果中我们可以看到,错误日志文件的位置在 /www/wdlinux/mysql-5.5.27/var/kTWO.err

查看并分析MySQL错误日志

错误日志已经找到了,我们打开看一下,通过我的分析,我的这个MySQL运行出错有多处,但是直接导致MySQL宕机的只有一处。日志内容如下:

170806 14:33:23 mysqld_safe Number of processes running now: 0
170806 14:33:23 mysqld_safe mysqld restarted
170806 14:33:23 InnoDB: The InnoDB memory heap is disabled
170806 14:33:23 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170806 14:33:23 InnoDB: Compressed tables use zlib 1.2.3
170806 14:33:23 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
170806 14:33:23 InnoDB: Completed initialization of buffer pool
170806 14:33:23 InnoDB: Fatal error: cannot allocate memory for the buffer pool
170806 14:33:23 [ERROR] Plugin 'InnoDB' init function returned error.
170806 14:33:23 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
170806 14:33:23 [ERROR] Unknown/unsupported storage engine: InnoDB
170806 14:33:23 [ERROR] Aborting

上面的错误日志是MySQL运行停止的最近一次错误提示。

分析得知,The InnoDB memory heap is disabled这个错误导致了下面一系列的failed和ERROR,最终导致最好的Aborting(异常终止)。这句话的大概意思就是InnoDB内存堆是禁用的。

通过查阅资料发现,MySQL默认的配置使用了操作系统的内存分配器,禁用了InnoDB的内置内存分配器所至。默认的innodb_use_sys_malloc配置是决定内存的分配器,当配置为1时是使用操作系统内存的分配器,当配置为1时使用InnoDB的默认分配器。所以我们只要将这个配置修改为0即可。

解决方案

找到MySQL的配置文件修改innodb_use_sys_malloc配置项为0.

一般的MySQL配置文件位置在/etc/my.cnf

查看配置文件中的配置后发现了一个尴尬的问题,竟然没有找到这个innodb_use_sys_malloc配置项。原来MySQL在版本升级的时候曾经取消了这个配置。但是人工添加上也是可以生效的。

我们直接在[mysqld]下面直接添加innodb_use_sys_malloc=0即可。

然后重启MySQL服务,再次查看日志。

170806 16:43:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170806 16:43:51 InnoDB: Compressed tables use zlib 1.2.3
170806 16:43:51 InnoDB: Initializing buffer pool, size = 128.0M
170806 16:43:51 InnoDB: Completed initialization of buffer pool
170806 16:43:51 InnoDB: highest supported file format is Barracuda.
170806 16:43:51  InnoDB: Waiting for the background threads to start
170806 16:43:52 InnoDB: 1.1.8 started; log sequence number 6012940
170806 16:43:52 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
170806 16:43:52 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
170806 16:43:52 [Note] Server socket created on IP: '0.0.0.0'.

发现之前的错误消失了,没有faild和error了。经过这几天的测试发现,宕机的问题已经解决了,没有再发生。

附上错误日志中的其他几个小问题的解决方案

第一项

170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution
170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution
170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution
170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution
170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution
170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution
170804 21:51:16 [Warning] IP address '182.18.22.153' could not be resolved: Temporary failure in name resolution

在日志中出现了大量的类似警告。

这个警告是在说找不到DNS服务器,在web服务中,很多的服务器都没有DNS服务,所以MySQL提示无法将该IP解析为主机名。

解决方案:在MySQL配置文件中[mysqld]添加skip-name-resolve,这将使MySQL不再通过DNS解析地址。

这个问题的解决还有一个方式,那就是在host文件中添加ip信息,但是这个方案并不可取,ip太多不可能全部添加上。

第二项

170805 17:42:57 [ERROR] Missing system table mysql.proxies_priv; please run mysql_upgrade to create it

上面的错误提示找不到系统的数据表mysql.proxies_priv,这个问题的来源在于我当初升级MySQL版本的时候没有更新系统数据表,导致新版的MySQL数据表不全。

解决方案:执行命令mysql_upgrade -u root -p  输入密码之后将自动更新修复系统数据表。

PS:以上问题都是博主亲自遇到并解决的经验之谈,难免有不到之处,若有不当还请各位指正。若问题依然没有解决可参见《解决MySQL经常停止运行(swap分区设置)》

留下脚印,证明你来过。

*

*

流汗坏笑撇嘴大兵流泪发呆抠鼻吓到偷笑得意呲牙亲亲疑问调皮可爱白眼难过愤怒惊讶鼓掌