高可用失灵：交换机导致Oracle集群故障致机场停运

最近日本的一则数据库故障引发了全日航空（ANA）航班停运，被广泛关注。

据日本《产经新闻》3月22日报道，日本全日空航空公司（ANA）的国内航班系统22日8时20分开始发生故障，导致旅客无法办理登机手续，目前正在逐步恢复。但截至22日下午2时，已有超过120架航班停航。 今年2月24日，ANA国内航班系统就曾经发生故障，但30分种后修复，导致一部分航班晚点起飞。在2007年5月27日和2008年9月14日，也出现超过400架航班晚点或停航的故障。报道称，此次故障导致在羽田机场、大阪机场、那霸机场等出发的飞机出现延误。目前正在调查原因。

近日，网友提供了此次故障进一步的详细原因：

【全日空发生系统故障120个航班被取消】日本全日空航空公司（ANA）的国内航班系统3月22日发生故障，乘客无法办理登机手续、订票系统也瘫痪。发生ORA-29740错误，Oracle节点被踢出集群，若干数据库实例宕掉。可能是网络交换机故障引起的集群心跳信号传递异常，最后更换了交换机。

在Oracle的手册中，对于ORA-29740描述如下：

Description:Evicted by member string, group incarnation string Error Cause:This member was evicted from the group by another member of the cluster database for one of several reasons, which may include a communications error in the cluster, failure to issue a heartbeat to the control file, etc. Action:Check the trace files of other active instances in the cluster group for indications of errors that caused a reconfiguration.

其主要描述是指：RAC节点被集群中其他节点因故驱逐。

正常情况下，Oracle的RAC多节点就是为了实现业务连续性和高可用，一个节点故障通常不会引起整个数据库不可用。但是在这次事故中，显然服务全部失去。网友透漏的消息称：可能是网络交换机故障引起的异常，最后更换了交换机。

进一步的消息指出：

【导致全日空(ANA)120个航班被取消的票务系统故障是CISCO交换机引起的】造成Oracle Cache Fusion的UDP通讯异常，4节点的Oracle RAC无法重组集群。本来交换机是有主备设计的，但是主交换机并未彻底坏掉，而是处于不稳定状态，备用交换机不知道主交换机出了故障所以没有接管。

以上爆料的消息指出，交换机故障，处于不稳定状态，备用交换机未接管，导致Oracle RAC集群无法重组，故障蔓延至全局。

在Oracle RAC集群环境中，类似故障最常见的情形是，当实例间发生通讯故障等，故障实例不能发送心跳信息（heartbeat）时，为避免数据损坏，失败节点会执行自我驱逐（Evict Self）以脱离集群组，节点驱逐的过程会抛出ORA-29740错误，记录在Alert日志中，并生成跟踪文件。

在节点驱逐之后，数据库还需要实现集群重配置，与此相关的概念有Instance Membership Recovery (IMR)，Instance Membership Reconfiguration.常见的故障信息类似如下：

opiodr aborting process unknown ospid (75852) as a result of ORA-28 LMON (ospid: 767522) detects hung instances during IMR reconfiguration LMON (ospid: 767522) tries to kill the instance 2. Please check instance 2’s alert log and LMON trace file for more details. USER (ospid: 32900426): terminating the instance due to error 481 Errors in file /oracle11g/PROD00/PROD001/trace/PROD001_lmon_767522.trc: ORA-29702: error occurred in Cluster Group Service operation System state dump is made for local instance System State dumped to trace file /oracle11g/PROD00/PROD001/trace/PROD001_diag_9373174.trc Instance terminated by USER, pid = 32900426

如果检查LMON进程可以看到类似如下信息：

kjxgmrcfg: Reconfiguration started, type 6 CGS/IMR TIMEOUTS: CSS recovery timeout = 31 sec (Total CSS waittime = 65) IMR Reconfig timeout = 75 sec CGS rcfg timeout = 85 sec kjxgmcs: Setting state to 274 0. kjxgmpoll: CGS state (274 1) start 0x51482867 cur 0x514828bc rcfgtm 85 sec kjxgmpoll: the CGS reconfiguration has spent 85 seconds. kjxgmpoll: terminate the CGS reconfig. Error: Cluster Group Service reconfiguration takes too long LMON caught an error 29702 in the main loop error 29702 detected in background process ORA-29702: error occurred in Cluster Group Service operation

ANA的系统故障持续超过5个小时，在国内重要企业都应该算得上是重大事故。虽然Oracle RAC集群是久经考验的高可用架构，但是其单点数据存储和集中式架构在极端情况下仍然可能遭遇单点，所以构建可切换的灾备系统或者降级支持系统，对于核心企业业务架构来说是必不可少的。

在当前的企业级架构中，通过双活、灾备、读写分离等解决方案都可以作为数据库高可用的有益补充。云和恩墨持续为提升用户系统高可用而提供不断演进的技术解决方案！