【全局出发，追根溯源】一则集群故障案例分析

作者简介：

董冰，混迹DBA圈子十余载的闲云野鹤，曾服务过政府行业、银行数据中心、互联网游戏上市公司，辗转蛰伏于中国铁塔，励志做一个社会主义的螺丝钉。

故障场景描述：

业务系统和监控同时反映11G的两节点RAC数据库无法连接（非负载均衡，优先连接节点1），DBA尝试登陆节点1服务器,SSH无响应，尝试登陆节点2，成功，发现节点2状态正常，建议应用重启连接池，尝试主动连接节点2先恢复生产，随后尝试对节点1故障进行恢复分析。

故障原因分析：

查看RAC alert日志，发现RAC Brain Split把节点1服务器强制重启了。

一般这个时候，大部分DBA会开始深挖各种集群日志，把发现的异常代码拿到support.oracle.com上去寻求支持。这对RAC alert日志的分析做经常会耗费大量精力和时间，结果往往会陷入一连串不可描述的BUG案例，比如：

在本案中，DBA没有对RAC的日志做过多的比对分析，而是把精力放在复原节点1服务器崩溃前的故障场景上。好在现场有各种手段对数据库及服务器的运行状态进行了监控和记录，很方便进行场景推演。

首先，查看数据库的运行监控图表，发现在节点1崩溃前，数据库IO负载有非常明显的增加：

引起数据库逻辑读和物理读飙升的原因基本的是因为糟糕的SQL代码被突然并发调用或者是因为异常的维护操作造成索引失效，一般伴随的是大量操作系统CPU/内存/IO资源的消耗。SQL的事先放放，继续看看操作系统方面的变化。

先看内存，发现节点1宕机之前有物理内存大量消耗的趋势：

再看CPU 负载，在故障时间点前（16：00）也有较明显的升高趋势：

另外还通过ZABBIX查看了包括网卡、IO负载等信息。很遗憾的是，由于从16点开始节点1服务器就无法响应了，外部监控采集到的信息出现的断档。虽然有趋势但是没有绝对的证据显示资源最终的消耗情况。

幸好，我们在服务器本地还部署了OSWatcher来作为服务器信息记录的手段。这样在外部访问失效的情况下，我们可以在本地获取到更多服务器崩溃前的信息。

我们在故障时间点的TOP和VMSTAT快照中看到了节点1临终前的状态：

1、物理内存消耗殆尽

2、开始使用SWAP分区

3、集群守护进程开始出现异常:GIPCD.BIN消耗大量CPU

4、操作系统CPU system time飙升

5、从16：06到16：16服务器夯死，随后服务器重启

分析到这里基本上就可以对节点1重启的故障进行一个场景推演了：

数据库爆发大量性能低下的SQL--> 数据库消耗了大量服务器资源-->服务器物理内存资源耗尽-->数据库集群软件状态异常-->系统进程夯死-->服务器重启

现在回到开始关于运行稳定的生产系统突然出现高负载SQL的话题，一般遇到这个情况，可以尝试先排除在关键业务表上是否出现失效的索引，因为遇到过在线上生产系统使用SQLLOAD加载数据导致索引失效引发业务崩溃的场景，你都不会知道前台开发人员会做什么事情。

经验总结：

建议DBA在处理数据库异常的问题时，跳出对数据库本身异常日志内容分析的范畴，要从操作系统、服务器硬件甚至更高的视角来分析整个异常现象。因为在很多公司，DBA和SA各司其职，界面分工比较清楚，但是在处理尤其是集群环境的异常时，却很容易发生互相甩锅的情况，最后失去了发现问题源头的机会。