春节将至，多数企业的数据库都处于“封网”状态，即停止升级、割接、设备入网、代码变更等工作，但1月18日暴雪娱乐和网易公司联合发布的一则数据丢失导致游戏《炉石传说》故障的公告点燃了朋友圈。

       公告称《炉石传说》由于供电意外中断导致数据丢失，不得不将数据回档。一纸公告将《炉石传说》推上了舆论的风口浪尖，也让习惯性低调围观的DBA们沸腾了。

       《炉石传说》数据库丢失，真的仅仅只是因为供电问题？一边，各路DBA纷纷探索故障背后的种种原因，听起来好像是那么一回事情。另一边，架构师在分析和猜测《炉石传说》游戏架构的同时，不忘提出一堆高大上的解决方案。

       在复杂的系统中，一个看似不经意的操作可能会引起一连串的连锁反应，亚马逊雨林那只蝴蝶翅膀扇扇翅膀，也许两周后就会引起美国得克萨斯州的一场龙卷风。很多时候我们无法防止灾难的发生，但扪心自问，当灾难来临时，你和你的数据库准备好了吗？

       外行看热闹，内行看门道。美创资深DBA从技术角度来分析分析。

       从《炉石传说》服务器故障公告开始说起。

       我们先不去讨论炉石生产数据库的存储保护机制，换个角度，从DBA最容易忽略的数据库备份机制谈起。

       根据公告所言，数据损坏源自于供电意外中断，那几乎可以得出这样的结论：数据库由于异常断电导致了数据库物理坏块(假设公告是真实地描述事实)。

       数据库出现坏块的一个典型症状就是公告里提到的“游戏环境变得不稳定”，也就是说数据库坏块还没有导致数据库宕机。当然了，如果数据库有备份，数据库坏块并不可怕，我们只要恢复数据库即可。但最为致命的是，“相关的备份数据库也出现故障”。正如DBA们最敬畏的墨菲定律，不该发生的最终还是发生了，而且炉石这一故障恰巧发生在春节前的业务高峰期（很多人都会选择放假玩游戏）。

       根据上述分析，我们又可以得出另外一个结论：数据库和备份位于在同一个机房，或者是位于同一个存储中。所有的鸡蛋放在同一个篮子里，一荣俱荣，一损俱损啊。

       再细看公告，认真抠字眼，公告中在论及“相关的备份数据库也出现故障”时并没提到任何容灾字眼，而且“游戏的维护时间超过24小时”。

       所以，我们有理由相信，炉石数据库并没有部署容灾系统，或者是部署的容灾系统并没有一套完善的应急响应机制而导致不敢切换。

       后者可能性较小。因为故障发生后，DBA们在“最初两天尽力做出其他的各种尝试”，我们可大胆猜测，暴雪的DBA应该在后台全力修复坏块，但不幸的是，数据库坏块面积过大及比较严重，修复不成功。

       游戏数据丢失，对于玩家来说，无疑是一场灾难。暴雪和网易综合考虑给出解决方案，将游戏数据回档至事故发生前状态（即2017年1月14日15:20）并给于玩家补偿。

       问题来了，数据库如何做到“回档”呢？可能会使用到以下四种技术：

1、 使用数据库自身的一致性读特性，如使用以下命令闪回某张表的数据：

create table t as select * from t as of timestamp to_timestamp ('2017-01-14 15:20:00','yyyy-mm-dd hh24:mi:ss');

由于数据库存在物理坏块且闪回时间跨度过长（超过3天），使用这种技术可能性很小。

2、 使用数据库自身的物理闪回技术，如Oracle在打开闪回特性后可以使用以下命令闪回整个数据库到2017年1月14日15:20：

flashback database to timestamp to_timestamp('2017-01-14 15:20:00','yyyy-mm-dd hh24:mi:ss');

但根据前面分析，数据库出现了物理坏块，所以使用这种技术可能很小。

3、 作为一个高知名度的互联网公司，生产数据库并不会单个存在，而是会在其周围建立一个数据库生态圈。即生产库中的数据会通过数据同步软件建立查询库、数据仓库等数据库。当炉石生产数据库发生物理坏块导致某些核心数据不能访问时，DBA在修复坏块无果的情况下，很可能通过其他数据库将数据重构回来，但也只能重构数据到故障发生前的数据。根据公告，故障处理时间已超过3天，很可能是因为数据库过大，重构数据耗时长。由此可见，持续为数据库减肥，保持数据库容量不变，是非常重要且必要的，当灾难来临时，轻量级的数据库可以有效地减少数据库的恢复时间。

       如今,数据库的灾备和安全已成为时代主题,但在数据库运维过程中仍很不太平,灾难的达摩克利斯之剑依然悬在DBA头上。美创科技运维服务中心维护的数据库数量高达2000套以上，拥有丰富的实战运维经验。

       结合IDC灾难报告统计结果，硬件失效和人工出错导致灾难发生的比例高达76%。如下图所示：

        在炉石数据库故障中，我们总结出以下几点结论，主要如下：

一、 数据库的物理备份需要和数据逻辑备份相结合。需要提醒的是：

1、 备份和生产数据库绝对不能放在同一个存储上，否则备份就失去了很大一部分意义。

2、 数据库做了备份之后，不能置之不理，需定期对备份进行有效性测试，同时制定严格的恢复数据流程，了解故障恢复时间。

3、 数据库做了物理备份之后，依然存在数据无法恢复的风险，这和发起备份的频率和使用的技术有关。比如Oracle数据库，如果数据库为nologging模式时（select force_logging from v$database），那么即使数据库的物理备份有效且归档日志健全，开发人员在数据库备份完成后、下一轮数据库备份发起前，对某张业务表进行了nologging操作，该业务表从物理备份集恢复出来之后，会出现如下错误：

SQL> select * from t;

ORA-01578: ORACLE data block corrupted (file # 11, block # 84)

ORA-01110: data file 4: '/oradata/users.dbf'

ORA-26040: Data block was loaded using the NOLOGGING option

二、 数据库在容灾建设过程中，我们在选型容灾产品的时候必须考虑以下因素：

1、 选数据库自带的容灾产品，如Oracle DataGuard。虽然数据库兼容性较好，但需要DBA具备较强的运维和故障处理能力。

2、 选商业容灾产品，除价格外，还需重点考虑以下因素：

a) 容灾产品的稳定性。这是第一要素。数据库发生灾难时，容灾产品是业务能否正常进行的重要保障。此外，容灾产品必须具备完善的自我监控机制，当容灾产品发生故障时，能够提醒DBA和产品售后团队及时介入处理。

b) 恢复点目标（RPO），最大可以忍受的数据丢失量。严格来讲，容灾产品的数据丢失率应该为0或者无限趋向于0。

c) 恢复时间目标（RTO），最大可以忍受的业务终止时间。当灾难发生时，容灾产品的切换时间越短越好。一般情况下，应控制在5分钟以内。

d) 强大的售后团队支撑。当发生灾难时，一线DBA往往会由于缺乏经验而手足无措，如有强大的售后团队及完善的应急响应流程，将最大程度地降低业务损失。

e) 容灾设备能否最大化利用。建设容灾系统相当于给数据库购置了保险，所以在数据库生命周期内很可能都没有真正使用过一次。目前市场上有部分的容灾产品可以在容灾端提供只读查询操作。为了减轻生产库的压力，应用可以将部分查询操作转移到容灾端上去运行。值得一提的是，美创DBRA物理级别容灾从Oracle 10g开始，就提供了灾备端实时查询功能。

f) 在容灾建设过程中，数据库不是单独的个体，应将数据库之外的应用系统的容灾建设也考虑在内。否则，失去了应用系统的数据库，只是一个存储数据的介质而已。

需要提醒的是，

1、 目前市场上绝大多数存储级别容灾产品都不能防止逻辑错误及误操作，如在生产库发起了一条误删除数据命令，实时会将误删除的数据传播到容灾端。美创科技DBRA灾备产品能有效的防止逻辑错误传播、挽救被误操作的数据。

2、 任何容灾产品上线之后，必须定期进行切换演练或者桌面演练，形成完整的灾难应急处理流程和手册。美创科技DBRA灾备产品可以在不影响生产系统正常运行的的情况下，随时校验容灾系统的数据是否正常。

三、当前很多数据库处于三库一体状态，即生产库、开发库和测试库都是在同一个数据库中完成，进而导致了误操作和数据泄露频繁发生。美创把核心数据从普通业务数据中脱离出来独立管理，将核心数据分级分类，选择核心表格组成敏感数据集合，在保障安全的基础之上实现方便管理。美创CAPAA堡垒机强调核心数据保护，防止误操作及人为篡改数据。