MySQL数据库OOM故障报告
-
故障描述
2017年5月23日10:43分,MySQL生产库的vip 10.72.16.1突然漂移到备库上,但是vip在备库上并没有对外提供服务,从而造成所有MySQL项目出现业务中断。
2 故障造成的影响和范围
影响部门
影响业务
影响级别
影响业务时长(分钟)
影响业务使用说明
是否影响业务收入
集团所有MySQL项目
HR、OA等
严重
17分钟
业务系统无法访问。
NULL
-
故障根本原因
经检查,MySQL主库出现故障的原因为,MySQL主库服务器内存溢出,发生经典的OOM事件,从而导致MySQL进程自动重启。然后MHA进程检测到主库不可用,从而将vip漂移到备库上。
当备库接到vip后,不能对外提供服务,从而导致业务中断。
-
解决办法
由于MySQL备库vip没有对外提供服务,于是管理员手工将vip强制绑定到主库服务器上,使业务恢复正常。
待业务恢复正常后,管理员再重新调整MHA,使高可用环境恢复正常。
-
故障描述
10:43分:管理员收到监控系统微信报警,提示MySQL vip 10.72.16.1 is down。
10:45分:经检查,确认故障原因为mysql vip漂移,导致所有mysql项目不可访问。
11:00分:管理员强制将vip绑定到主库上,使业务恢复正常。
11:00-17:30:分析故障原因,重新恢复MHA高可用架构。
原因分析过程:
a)、通过查看MHA日志:得知MySQL主库不可用:
[root@Mysql03 log]#cat /etc/masterha/log/manager.log
Tue May 23 10:43:12 2017 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.72.16.1' (4))
b)、通过查看mysql主库日志,得知MySQL主库自动重启过:
[root@MySQL02 ogg]# cat /data/MySQL02.log
170523 10:43:18 mysqld_safe Number of processes running now: 0
170523 10:43:18 mysqld_safe mysqld restarted
c)、通过查看主库操作系统日志,得知服务器内存溢出,操作系统把mysql进程杀了:
[root@MySQL02 ogg]# cat /var/log/messages
May 23 10:43:11 MySQL02 kernel: mysqld invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_score_adj=0
May 23 10:43:11 MySQL02 kernel: Out of memory: Kill process 2805 (mysqld) score 572 or sacrifice child
May 23 10:43:11 MySQL02 kernel: Killed process 2805, UID 501, (mysqld) total-vm:40020568kB, anon-rss:28494756kB, file-rss
:6360kB
d)、以下是nagios监控出的MySQL主服务器内存使用情况,可以看到操作系统内存使用率之前一直是80%,但在10:43分时,内存使用率骤降,直到11:00时才将业务恢复,内存使用率升到60%。
-
故障结论
本次故障主要是服务器内存满了,导致MySQL进程自动重启,即OOM。
我们的MySQL操作系统内存是32G,分给MySQL 的innodb buffer pool是24G(是物理内存的80%),所以,MySQL服务器的内存使用率一直维持在80%,如下是近一个月的内存使用情况:
那MySQL居然一下子占用了80%的物理内存,MySQL占用这么多内存都干嘛了,这个可以通过show engine innodb status \G命令查看:
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 26373783552; in additional pool allocated 0
Dictionary memory allocated 5848065
Buffer pool size 1572860 (innodb buffer pool大小:1572860*16k=24G)
Free buffers 62632 (空闲列表大小:62632*16k=1G)
Database pages 1470451 (LRU列表:1470451*16k=23G)
Old database pages 542959
Modified db pages 0
Pages made young 1445, not young 0 (把LRU列表中间的冷数据移动到头部变成热数据的次数)
通过上面可以看出,数据库innodb buffer pool确实占用了23G内存给了LRU列表。
下面再看LRU列表都存了哪些数据:
select PAGE_NUMBER,PAGE_TYPE,TABLE_NAME,INDEX_NAME,DATA_SIZE from information_schema.INNODB_BUFFER_PAGE_LRU;
通过上图可以看到LRU列表中缓存的是auod库下一些表。
-
优化措施
有以下两种方案:
a)、调小innodb buffer pool的大小,将24G改成16G,留出更多的内存给操作系统。
b)、增加操作系统的内存,由32G调整到64G,整体提高数据库性能,避免OOM。
-
总结
建议将数据库操作系统内存由32G升高到64G。
完。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28916011/viewspace-2139760/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/28916011/viewspace-2139760/