盖国强：《炉石传说》大故障，不要以为你也可以幸免

《盖国强：《炉石传说》大故障，不要以为你也可以幸免》要点：
本文介绍了盖国强：《炉石传说》大故障，不要以为你也可以幸免，希望对您有用。如果有疑问，可以联系我们。

作者简介

盖国强

中国地区首位Oracle ACE和ACE总监,中国地区最著名的Oracle技术推广者之一,他的专著《深入解析Oracle》、《循序渐进Oracle》等书籍受到Oracle技术爱好者的广泛好评.

2010年,与Oracle ACE总监张乐奕先生共同创立ACOUG(中国Oracle用户组),持续推动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第一守则：备份重于一切

（编辑：ASP站长网）