OOM导致MySQL服务被kill案例一则

看到这个 故障分析 | mysql oom 故障应如何下手，想起来几天前也遇到一次mysql服务因为oom被杀掉的情况，记录一下

 

背景：
一个测试环境，由于centos系统上没有设置虚拟内存，运行的mysql实例buffer_pool_size配置的有不合理，运行了一个较大的查询

现象：
前端工具执行某个sql，一点击执行，过几秒钟连接客户端显式断开mysql连接，第一次没在意，以为是刚好遇到网络问题导致的。
因此又重新刷新连接，重新执行，然后又数据库连接又断开，于是又刷新连接，又执行又断开……，奇怪的是每次反复连接断开连接断开连接断开……
完全相同的现象反复几次之后，才意识到哪里好像的不对劲，难特么道谁在玩我？
感觉是mysql服务被重启了，因为网络不可能总是在执行查询的时候出现故障，于是查看mysql启动时间：

select date_add(now(),interval -variable_value second) as startup_datetime 
from performance_schema.global_status where variable_name = 'uptime'

果不其然，从当时的时间点来看，刚刚启动了不到一分钟，看mysql的errorlog，只是反复记录mysql重启恢复，starting crash recovery...，crash recovery finished.

mysql自身的errorlog中是看不到什么问题了，只能拉出来系统日志，mysql的服务进程竟然是oom后被系统杀掉了，然后才回头追溯各种配置，/var/log/message

后面其实还是有点疑惑，为什么没有吧这个oom的信息记录到mysql自己的error log中呢？mysql自己的error log也只记录了重启恢复的过程。
可能是，连mysql自己都被杀掉了，谁来记这个日志呢。
不过好在是，mysqld进程被杀掉之后，一直在自动被唤醒，这下可以深刻地一直到mysql_safe进程的作用了，

 

教训
包括数据库和操作系统在内，一些基础配置还是要做好的，mysql的配置可以自己把控，虚拟内存究竟多大，专业的事交给专业的人，也是一个专业问题。