689
高可用失靈：交換機導致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集群是久經考驗的高可用架構，但是其單點數據存儲和集中式架構在極端情況下仍然可能遭遇單點，所以構建可切換的災備係統或者降級支持係統，對於核心企業業務架構來說是必不可少的。
在當前的企業級架構中，通過雙活、災備、讀寫分離等解決方案都可以作為數據庫高可用的有益補充。雲和恩墨持續為提升用戶係統高可用而提供不斷演進的技術解決方案！
本文出自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 17:33:38