深夜一声惊雷.客户炸了群

深夜惊雷.客户炸群

  深夜一声惊雷，窗外，大雨倾盆而下，雨滴噼里啪啦地打在窗户上，拿起手机一看，2套Oracl RAC 集群同时宕掉了，信息还在不停的刷新着。
  急忙打开电脑连上vpn查看日志，同时打电话给上级领导汇报情况。不到10分钟客户群炸锅了。2个主业绩线数据库不可用，想想就汗如雨下。

现场分析

  发现集群日志一直再报crs 盘IO error,当时第一反应是crs盘损坏了。

• grid 日志
  

  查看一下多路径的状态，发现所有的路径都是： failed ，当时方向指向了光纤交换机或存储，于是赶快给我们的存储工程师打电话确认，让其确认光纤和存储状态。
  果然存储工程师反馈存储界面 三块硬盘状态都故障了 ，大大的“incredible”，三块硬盘一起坏了，这“幸运”职业生涯头一次啊。

• 多路径状态：
  

• oracle 日志
  

• 系统日志
  

• 注：为啥2套RAC一块宕，因为用一了套存储。请不要吐槽这种架构，因为是客户当时为了节省成本！

• 后续处理

  联系机房更换了硬盘没一会又故障了，联系厂商需要现场排查问题，考虑到业务不能再等了，于是领导决定启用备库恢复业务，RAC环境继续维修，如果能抢修过来到时候重做DG-RAC再切回来（此次领导与甲方沟通环节略）。于是来了一次Failover操作，幸亏我们每年都会做一次灾备演练，今年上个月演练完。

• Failover操作
  
• 调整process(以前是双节点RAC，连接需要考虑)
• 程序修改配置，启动程序，测试，上线的同时，我调整数据库redo大小，组数…。
• 禁用thread 2

 alter database disable thread 2;

• 重新搭建备库继续保持容灾性。
• 存储被厂商拉回检查了。
• 重新规划架构，按业务线分离存储，各一套RAC环境，避免相互影响，否则人手真不够用。

总结

• 存储日志其实在今天中午已经有日志异常提醒了，只是监控不完善。
• 共用环境确实能节省成本，但风险也是共担的，压力也是双份的。
• 启动完备库后，需要考虑全面进行调整,例如在启用备库，维护RAC的同时避免和程序连接误连RAC导致数据不致，需要将RAC的防火墙闭掉所有应用IP。
• 一份经历，一份经验，一篇总结，一份收获。