MySQL数据库OOM故障报告

MySQL数据库OOM故障报告

 

1. 故障描述

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

    

   2 故障造成的影响和范围

影响部门

影响业务

影响级别

影响业务时长(分钟)

影响业务使用说明

是否影响业务收入

集团所有MySQL项目

HR、OA等

严重

17分钟

业务系统无法访问。

NULL

 

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

    

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%。

 

 

 

 

1. 故障结论

   本次故障主要是服务器内存满了，导致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库下一些表。

 

1. 优化措施

   有以下两种方案：

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

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

    

2. 总结

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

    

    

   完。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28916011/viewspace-2139760/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28916011/viewspace-2139760/