UDN-企业互联网技术人气社区

板块导航

浏览  : 1340
回复  : 0

[讨论交流] 高可用失灵:交换机导致Oracle集群故障致机场停运

[复制链接]
cc小厨子的头像 楼主
发表于 2016-4-22 15:28:05 | 显示全部楼层 |阅读模式
本帖最后由 cc小厨子 于 2016-4-22 15:30 编辑

  来源: 盖国强 Oracle

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

8a5c7bd0da6b4ce6774ea9fc81ce0b95.png


  据日本《产经新闻》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节点被踢出集群,若干数据库实例宕掉。可能是网络交换机故障引起的集群心跳信号传递异常,最后更换了交换机。

7777b8d3cd4201d2a8202b4225a64758.jpg


  在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交换机引起的】造成OracleCacheFusion的UDP通讯异常,4节点的OracleRAC无法重组集群。本来交换机是有主备设计的,但是主交换机并未彻底坏掉,而是处于不稳定状态,备用交换机不知道主交换机出了故障所以没有接管。

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

12620b014bc80f923fc8223f8a11000a.jpg


  在OracleRAC集群环境中,类似故障最常见的情形是,当实例间发生通讯故障等,故障实例不能发送心跳信息(heartbeat)时,为避免数据损坏,失败节点会执行自我驱逐(EvictSelf)以脱离集群组,节点驱逐的过程会抛出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个小时,在国内重要企业都应该算得上是重大事故。虽然OracleRAC集群是久经考验的高可用架构,但是其单点数据存储和集中式架构在极端情况下仍然可能遭遇单点,所以构建可切换的灾备系统或者降级支持系统,对于核心企业业务架构来说是必不可少的。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部