
问题背景
在多个月之前,也就是服务器刚刚搭建的时候,标题中的MySQL问题就出现了,很是奇怪,博客过一段时间就毫无征兆的挂掉了,提示连接数据库失败,然后重新启动一下MySQL服务就又可以正常运行了。但是这个问题总是像莫名其妙的发生,时不时的给我来一点小惊喜,小意外,我每次重启MySQL服务之后就又可以正常运行了,所以就没去怎么解决这个问题。但是最近真的是忍无可忍了,决定解决了它。
先说一下我的服务器情况:
服务器:CentOS 6.8
MySQL版本:5.5
找到MySQL错误日志文件位置
解决问题当然是要看问题出在哪里,好在MySQL有自己的错误日志可以供我们分析。那么错误日志在那里呢? 我们可以用下面的方法找到这个文件的位置:
第一步:登录MySQL终端;
第二步运行下面的命令来查找错误日志的文件位置;
|
mysql> show variables like '%log_error%'; |
输出如下:
|
+---------------+----------------------------------------+ | 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宕机的只有一处。日志内容如下:
上面的错误日志是MySQL运行停止的最近一次错误提示。
分析得知,The InnoDB memory heap is disabled这个错误导致了下面一系列的failed和ERROR,最终导致最好的Aborting(异常终止)。这句话的大概意思就是InnoDB内存堆是禁用的。
通过查阅资料发现,MySQL默认的配置使用了操作系统的内存分配器,禁用了InnoDB的内置内存分配器所至。默认的innodb_use_sys_malloc配置是决定内存的分配器,当配置为1时是使用操作系统内存的分配器,当配置为0时使用InnoDB的默认分配器。所以我们只要将这个配置修改为0即可。
解决方案
找到MySQL的配置文件修改innodb_use_sys_malloc配置项为0.
一般的MySQL配置文件位置在/etc/my.cnf
查看配置文件中的配置后发现了一个尴尬的问题,竟然没有找到这个innodb_use_sys_malloc配置项。原来MySQL在版本升级的时候曾经取消了这个配置。但是人工添加上也是可以生效的。
我们直接在[mysqld]下面直接添加innodb_use_sys_malloc=0即可。
然后重启MySQL服务,再次查看日志。
发现之前的错误消失了,没有faild和error了。经过这几天的测试发现,宕机的问题已经解决了,没有再发生。
附上错误日志中的其他几个小问题的解决方案
第一项
在日志中出现了大量的类似警告。
这个警告是在说找不到DNS服务器,在web服务中,很多的服务器都没有DNS服务,所以MySQL提示无法将该IP解析为主机名。
解决方案:在MySQL配置文件中[mysqld]添加skip-name-resolve,这将使MySQL不再通过DNS解析地址。
这个问题的解决还有一个方式,那就是在host文件中添加ip信息,但是这个方案并不可取,ip太多不可能全部添加上。
第二项
上面的错误提示找不到系统的数据表mysql.proxies_priv,这个问题的来源在于我当初升级MySQL版本的时候没有更新系统数据表,导致新版的MySQL数据表不全。
解决方案:执行命令mysql_upgrade -u root -p 输入密码之后将自动更新修复系统数据表。
PS:以上问题都是博主亲自遇到并解决的经验之谈,难免有不到之处,若有不当还请各位指正。若问题依然没有解决可参见《解决MySQL经常停止运行(swap分区设置)》
2022年7月3日 22:01 沙发
后