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

database

看到这个 故障分析 | 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的配置可以自己把控,虚拟内存究竟多大,专业的事交给专业的人,也是一个专业问题。

 

以上是 OOM导致MySQL服务被kill案例一则 的全部内容, 来源链接: utcz.com/z/533390.html

回到顶部