前言

在一个阳光明媚的下午，电脑右下角传来一片片邮件提醒，同时伴随着微信钉钉的震动，打开一看，应用各种出错，天兔告警，数据库服务器内存爆红，Mysql数据库实例挂掉了。

排查

先交代一下数据库版本：

mysql> status -------------- mysql  Ver 14.14 Distrib 5.7.22-22, for Linux (x86_64) using  6.2  Connection id:          59568 Current database: Current user:           root@localhost SSL:                    Not in use Current pager:          stdout Using outfile:          '' Using delimiter:        ; Server version:         5.7.22-22-log Percona Server (GPL), Release 22, Revision f62d93c Protocol version:       10

崩溃故障排除绝不是一项有趣的任务，特别是如果MySQL没有报告崩溃的原因。例如，当MySQL内存不足时。

数据库邮件告警提醒发来的消息：

Type: mysql Tags: 生产主库 Host: 172.16.1.66:3306 Level: critical Item: connect Value: down Message: mysql server down

登录 Grafana 监控面板，数据库连接在哪个时间段曾有幅度的增长。

顺手检查一下之前的服务器邮件监控告警记录，上一个时间点，内存占用率99%，这说明了数据库连接的幅度增长，可能是压垮服务器的最后一根稻草。

其实导致OOM的直接原因并不复杂，就是因为服务器内存不足，内核需要回收内存，回收内存就是kill掉服务器上使用内存最多的程序，而MySQL服务可能就是使用内存最多，所以就OOM了。

Type: os Tags: 66数据库 Host: 172.16.1.66: Level: critical Item: memory Value: 99% Message: too more memory usage

查看系统日志

我们带着这个疑问来排查一下日志：

# 查看日志 tail -500f  /var/log/messages # 以下是 oom-killer Nov 27 14:55:48 itstyledb1 kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Nov 27 14:55:48 itstyledb1 kernel: mysqld cpuset=/ mems_allowed=0-1 Nov 27 14:55:48 itstyledb1 kernel: CPU: 2 PID: 895 Comm: mysqld Kdump: loaded Not tainted 3.10.0-862.3.2.el7.x86_64 #1 Nov 27 14:55:48 itstyledb1 kernel: Hardware name: Huawei 

                    

                        
关键字：