MySQL数据库OOM故障报告

1. 故障描述

   2017年5月23日10:43分，MySQL生产库的vip 10.72.16.1突然漂移到备库上，但是vip在备库上并没有对外提供服务，从而造成所有MySQL项目出现业务中断。

    

   2 故障造成的影响和范围

1. 故障根本原因

   经检查，MySQL主库出现故障的原因为，MySQL主库服务器内存溢出，发生经典的OOM事件，从而导致MySQL进程自动重启。然后MHA进程检测到主库不可用，从而将vip漂移到备库上。

   当备库接到vip后，不能对外提供服务，从而导致业务中断。

2. 解决办法

   由于MySQL备库vip没有对外提供服务，于是管理员手工将vip强制绑定到主库服务器上，使业务恢复正常。

   待业务恢复正常后，管理员再重新调整MHA，使高可用环境恢复正常。

    

3. 故障描述

   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

    

b）、通过查看mysql主库日志，得知MySQL主库自动重启过：

[root@MySQL02 ogg]# cat /data/MySQL02.log

c）、通过查看主库操作系统日志，得知服务器内存溢出，操作系统把mysql进程杀了：

[root@MySQL02 ogg]# cat /var/log/messages

d）、以下是nagios监控出的MySQL主服务器内存使用情况，可以看到操作系统内存使用率之前一直是80%，但在10:43分时，内存使用率骤降，直到11:00时才将业务恢复，内存使用率升到60%。

1. 故障结论

   本次故障主要是服务器内存满了，导致MySQL进程自动重启，即OOM。

   我们的MySQL操作系统内存是32G，分给MySQL 的innodb buffer pool是24G（是物理内存的80%），所以，MySQL服务器的内存使用率一直维持在80%，如下是近一个月的内存使用情况：

   

    

   那MySQL居然一下子占用了80%的物理内存，MySQL占用这么多内存都干嘛了，这个可以通过show engine innodb status \G命令查看：

    

通过上面可以看出，数据库innodb buffer pool确实占用了23G内存给了LRU列表。

下面再看LRU列表都存了哪些数据：

通过上图可以看到LRU列表中缓存的是auod库下一些表。

1. 优化措施

   有以下两种方案：

     a）、调小innodb buffer pool的大小，将24G改成16G，留出更多的内存给操作系统。

    b)、增加操作系统的内存，由32G调整到64G，整体提高数据库性能，避免OOM。

    

2. 总结

   建议将数据库操作系统内存由32G升高到64G。

    

    

   完。