关于炉石传说的Oracle数据库故障不要以为你也可以幸免

最近暴雪公司和网易的一则声明刷爆了朋友圈,大意就是由于『供电意外中断的原因而产生故障,导致数据损坏』,这样一则公告引发了一系列的猜想,我们在围观时仿佛人人都是诸葛亮,而事实上设身处地,我想在一次负责任的故障考验下,也许很少有人能够幸免。

如同阿里云会误删文件、京东会泄露数据、支付宝会被修改密码、携程会大面积瘫痪,在灾难来临之前,谁都会觉得自己是幸运者,而事实上,只是措手不及那次灾难还没有来到而已。

先回顾一下《炉石传说》长长的公告,然后我们再基于事实做一下分析吧:

首先,关于暴雪的核心数据库架构,不是网友猜测的MySQL(如果是 MySQL 就必然是分布式,不可能全部回档的),而是Oracle数据库。关键的系统架构如下(部分属于推测):

数据库:Oracle 架构:RAC + ASM 版本:12.1.0.2 (猜测) 节点数:4 (猜测) 系统:Linux 同步:GoldenGate

基于这样一些真实的基础和前提去讨论这次的事故,才更有意义。

以下是前一段时间暴雪招聘DBA Lead的条件要求,系统架构由此一目了然:要求深入理解Oracle内部原理、Oracle RAC和ASM技术,熟悉Golden Gate复制,熟悉Linux脚本编程

这些要求就深刻揭示了暴雪核心数据库的体系架构。在Linux上运行的基于ASM存储的Oracle RAC集群,使用OGG复制数据

在招聘中有一个特殊的要求,『Evaluate new releases and features of Oracle DBMS』,评估Oracle新版本和特性的能力,这一独特要求可能和当时要升级核心数据库有关,而升级版本就应该是12c,据此我推测其数据库版本应该已经追到最新版本12.1.0.2,国外的大公司风格基本如此,有了12.1.0.2,肯定不会有人守在12.1.0.1版本上,而且这套中国的系统是部署不久的独立系统

以下就是暴雪对于这个岗位的详细需求:

之前在互联网上已经披露了很多信息,包括一次故障的处理流程(来自搜索引擎):

1.9C在一次服务器故障中的说明,下面只列出关键部分 08:29 收到EVA存储报警邮件,联系数据中心工程师,联系惠普工程师. 08:35 故障应急流程启动,相关人员包括THE9/HP/Blizzard US . 15:33 Oracle专家加入故障应急流程 15:50 暴雪数据库工程师开始与Oracle专家继续分析故障情况. 17:15 暴雪表示暂时还未从他们的admin以及DBA处获得任何有新的消息,他们仍然在研究此故障。

当时的数据库运行在HP服务器上(大约2013年),现在已经迁移到Linux服务器上。

此外,暴雪的数据量很大,多年前Oracle 9i 时就是TB级别的数据库了,当然现在中国大陆地区肯定是独立的服务器,但是数据量也绝对会是TB级别的,再加上免费开放的热门程度,我推测两节点的RAC对中国玩家不够尊重,至少应该是4节点的Oracle RAC集群。

所以大家可能联想到了2016年年初的另外一则故障,在2016年3月22日,全日航空的故障导致了120个航班取消,据传是4节点RAC集群,由于网络问题导致故障:

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

我们再回过头来看暴雪的运维,最终看起来似乎没有找到合适的DBA Leader,所以内部晋升了一位,在LinkedIn上,这些信息是公开的:

好了,有了这些事实之后,我们再看公告就会清晰很多了。我们理一下时间轴:

  • 1月14日 15:20 (据说)因为供电问题,导致数据库损坏;
  • DBA开始修复,但是发现备份数据库也损坏了;
  • 数据库带病坚持工作,DBA同时开始在线修复;
  • 1月17日1点开始停机修复,修复预计8小时,未能按照预期时间完成;
  • 1月18日18:00发布公告,数据回档到1月14日 15:20,业务恢复;

外行看热闹,内行看门道

在了解了系统架构之后,从官方的信息里我们能够看到很多事实:

第一:故障出现在14日,应当早于15:20,公布时间推移,这是惯例; 第二:供电问题可能性不大,如果说成熟运营的IT,还存在单电单点是说不过去的,网易也不允许; 第三:数据库损坏应该是坏块,Oracle数据库在出现损坏故障时,仍然能够坚持工作的,应该是出现了坏块,坏块通常被大家疏忽,以为可解,所以拖延成了极慢长的次生故障; 第四:暴雪没有ADG的灾备,不可切换,请注意声明中明确说“备份数据库”而不是“备用数据库”; 第五:数据库依赖OGG进行复制,这个复制因为某种原因不能用于恢复,极可能因为Redo日志或 Undo 也有损坏,丢失了某些事务; 第六:最终坏块问题无法修复,只能选择基于时间点的不完全恢复,放弃了部分事务,也就是数据回档了,这是最无可奈何但是也是保证数据一致性的残酷选择; 第七:数据库的坏块,没有影响数据库运行,证明是小范围的损坏,不是文件级别的损失,这应当和存储的相关性更大,写丢失导致了数据块损坏; 第八:最初的8小时,是计划恢复部分表空间,但是没有解决问题,最终进行了全库恢复,根据这个停机时间预估数据库整体容量应当在10TB左右;

所以我们大胆推测:是因为存储故障导致了RAC集群写数据丢失,最终选择不完全恢复,放弃了部分数据

DBA第一守则:备份重于一切

如果大家还记得我曾经写下的DBA守则,没有备份对于DBA来说将会是致命的,而如果没有有效备份,那么备份也只能是心灵安慰。不论如何,备份至少可以给我们重来一次的机会,暴雪这一次最终救命的就是备份。虽然是回退到了14日。

既然备份这么重要,国内数据库的备份情况如何呢?云和恩墨白求恩平台最近发布的《中国2016年Oracle数据库运行现状报告》显示,有完整RMAN备份的数据库不到20%,24%的数据库甚至处于非归档模式下。

下图来自报告数据,可以看到其实国内的数据库的DG的使用率其实并不高,仅有21%:

Bethune 平台可以帮助大家检查RMAN备份完整性,Dataguard同步及时性,假期来临之前强烈推荐大家为数据库做一次健康检查。

关键节点是什么?

回顾一下,数据库带病坚持工作,这是整个案例最核心的一个决策,也就是说,通过在线运行,同时修复问题(坏块),向前走。

这也是一个艰难的决策,如此可以减少业务的中断,但是面临的风险就是可能最终数据不一致,需要回退或者承受复杂的校验工作。

大家可以想想我们面临这样的工作会如何处置?

我就此访问了浙江移动王晓征王总,他表达了他的观点:

我觉得得按照业务特性,事先约定优先保A(可用性)还是保C(一致性),如果没约定的话,如果我指挥,我会临机进行决断。

我非常赞同这一观点,有了事先约定,应急处置时才能有准则,不出现重大偏颇。

要一致性还是连续性?

如前所述,每一个DBA团队都应该有一个准绳,那就是在关键时刻,要保障一致性(准确性)还是连续性?

对于金融机构,毫无疑问,要保证数据库的一致性,在遇到故障时,可以果断中断业务提供,进行数据恢复或者修复;

而对于互联网业务等,可能连续性就更为重要,类似携程的业务,中断几天的服务是不可想象的;

王晓征就此总结说,在运营商系统建设的过程中,最初觉得业务连续性最为重要,但是当这些问题已经被较好的解决之后,现在觉得数据的一致性变得更重要起来,所以不同系统在不同阶段,就会有不同的取舍。

这是一个辩证的思考,也是运维发展到一定高度之后才能有的判断。

为何不切灾备?

关于这样严重的事故,为何不切灾备?

如前所述,从备份数据库的一字之别,我猜测这个系统根本就没有灾备,所以无从切换,毕竟这只是一款免费的游戏,在官网首页的显示『《炉石传说》官方网站_暴雪首款免费休闲卡牌网游』。

对于灾备的部署和切换,王晓征表示浙江移动内部是这样的:

按业务重要度,实现不同保障级别。

  • 一般系统:只做数据备份,无高可用,无容灾;
  • 重要系统:数据备份,高可用,无容灾;
  • 核心系统:备份,高可用(部分含柔性可用),容灾。

在实操层面,一般系统基本绝迹,目前以核心和重要系统为主。 如果出现数据损坏,核心系统肯定切容灾了,这种情况如果是硬件损坏或者删除数据文件引起的问题,基本就搞定了;当然,最怕的就是误操作或代码bug搞出来的数据丢失,可能把容灾端数据同时破坏,那就只能通过备份来恢复啦。

由此可以看出,即便有了完备的灾备环境,也很难防范所有问题,尤其是人为的误操作,所谓『功夫再高,也怕菜刀』,一个误删除可能就级联到所有的系统,再加上软件BUG不可避免,除了灾备,必然还要有可靠的备份来托底。

运维团队怎么配置?

大家还要思考一个问题,在处理复杂故障的时候,工作不能中断,但是人不能持续运转,在暴雪的这次事故中,从14日至18日,将近5天的时间,处理人员可能已经更替了几轮,如何延续处理思路、执行正确决策、保持核心战斗力,这也是运维要思考的重要因素。

如何幸存于类似事故?

好吧,我们谈一谈如何避免陷入这样的困境?以下是我们的一些思路,与大家商榷。

首先要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制,但是这套备份机制能否真实奏效是需要检验的。我接触过某大型企业,投入巨资兴建的灾备中心,从未正式切换过,这样的灾备在故障来临时也很难有人拍板去进行切换,所以备份的有效、容灾手段的有效是必须确保的。注意,备份的恢复速度必须足够的考虑到,磁带的低效备份关键时刻会害死人。

其次,要有完善的故障处理策略和流程。对于不同系统,在关键时刻要优先确保什么,是要订立规则的,有了规则才能照章办事,不走错方向,不无辜背锅。几年前某国内金融系统出现数据坏块,同样选择了带病修复,最终没能解决问题,同样选择了回档承担了数据损失。

再次,要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案,从业务端同样要有对应的预案,以便应急时同步处理,区别对待。很多时候,有了业务上的应急、降级服务方案,技术层面的处理就能够从容许多。

最后,要有能够快速协同的团队资源。很多时候严重的故障,需要较大规模的专业团队协作处理,原厂商和第三方在其中都承载着重要的角色,所以关键时刻,要能够获得内外部快速及时的支持,尤其是在绵延数天的高强度工作中。

对于事后的补偿,19日暴雪已经给出了反馈,第一条就是“只要曾经在2017年1月18日18点之前登录过国服玩家,均可获得与25卡牌包等值的补偿”,越来越觉得,这次“营销”是很成功的。

感谢王晓征提供观点,欢迎大家留言回复您的观点,以上内容纯属猜测,猜对了也别告诉我。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-01-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

P4加入ONF和Linux基金会,推动P4的创新和采用

1384
来自专栏北京马哥教育

如何接手一个新业务的运维工作

如何接手一个新业务的运维工作?有些东西我们还是要把话说在前面,以免前期不明确造成后期工作的混乱。

920
来自专栏技术视点

17个混合云安全威胁及解决方案

反对者经常将混合IT云视为一种混乱的架构。但这并非混合IT云的问题,问题出在较差的网络执行、安全协议和管理上。无缝混合云的最大障碍是合规性不足、缺乏加密、风险评...

1819
来自专栏鹅厂网事

软硬件分离趋势及开放网络发展

1. 前言 一直以来,网络设备给人的感觉就一个或大或小的铁盒子,其貌不扬,让人猜不透里面到底是啥。而这种情况将有所改观,在OCP等开放组织、众多芯片商、ODM商...

2137
来自专栏FreeBuf

如何建立有效的安全运维体系

随着互联网行业的蓬勃发展,国内的黑客产业链早已达数十亿级别。除了各类网络攻击之外,一些黑客入侵情况也并不鲜见。这种事件相对于网络攻击有着更大的破坏力,系统被入侵...

2748
来自专栏FreeBuf

犯错是人的天性:如何减少人为失误造成的信息安全事故?

2014年IBM网络安全情报检索显示,高达95%的信息安全事件与人为失误(故意或无意)有关。人为失误不仅仅是影响网络安全的重要因素,同样在航空事故和医疗事故中扮...

1678
来自专栏区块链

真实案例讲解如何采取正确的措施防范ICS攻击

很多行业的工业控制系统(ICS),都可能遭受数据泄露、病毒、恶意软件、内部攻击或其它任何形式的攻击。令人遗憾的是,很多自动化工程师并没有意识到问题的严重性,说他...

1740
来自专栏FreeBuf

修不完的漏洞,微信跳一跳刷分泛滥成灾?

元旦假期前,微信小游戏功能上线,一款名为“跳一跳”的小游戏迅速在朋友圈刷屏。无需下载直接在微信小程序就可以玩,玩法简单、容易上瘾,还能与朋友PK。 ? 游戏和...

2328
来自专栏SDNLAB

SDN实战团分享(十一):SDN在企业网、企业DC中的应用

相信大家对SDN都有或多或少的了解,在这节省时间,关于SDN的历史和概要就不做详细介绍了,网上有大量相关知识和信息。今天主要想结合实际案例谈一谈SDN在企业网和...

26810
来自专栏企鹅号快讯

化妆品牌BeautyBlender网站感染恶意软件 顾客支付卡信息遭泄露

“用指尖改变世界” ? BeautyBlender是美国的一个化妆工具品牌,由好莱坞顶级化妆师Rea Ann Silva创立。谈到这个品牌,相信很多人都会首先想...

1897

扫描关注云+社区