记一次生产数据库意外重启的经历数据库

来源:互联网 / 作者:SKY / 2018-12-06 20:11 / 点击:
在一个阳光明媚的下午,电脑右下角传来一片片邮件提醒,同时伴随着微信钉钉的震动,打开一看,应用各种出错,天兔告警,数据库服务器内存爆红,MySql 数据库实例

记一次生产数据库意外重启的经历

前言

在一个阳光明媚的下午,电脑右下角传来一片片邮件提醒,同时伴随着微信钉钉的震动,打开一看,应用各种出错,天兔告警,数据库服务器内存爆红,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=0x201daorder=0oom_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 RH1288 V3/BC11HGSC0, BIOS 3.22 05/16/2016  

  Nov 27 14:55:48 itstyledb1 kernel: Call Trace: 

小伙伴们继续往下看:

0 pages HighMem/MovableOnly  

  Nov 27 14:55:48 itstyledb1 kernel: 291281 pages reserved  

阅读延展

1
3