《炉石传说》数据库灾难剖析之1--事件重现（原创）

2017年1月中旬，就在大家准备过新年之时，一则网络事故引爆了游戏界：

著名的游戏公司“暴雪”，开发的著名游戏《炉石传说》，由著名公司“网易”运维，
却发生了数据灾难，历经数天的抢救无果，数百万玩家的数据被迫回档4天。

除了游戏界，还有另外一个次元的人也在围观这一事故。
以稳定、可靠为第一金律的数据库技术界，面对网易的故障公告，眼镜掉了一地。
按官方说法，是机房停电导致数据+备份全部损坏，这。。。连外行人都不信。

从故障公告可以看出，整个事故历经4天，这中间，自然有故事，姑且我们来推测、重现一下。

2017年，今年的春节来得特别早，1月14日，大家都开始沉浸在过年的喜悦中，快要下班了。。。
突然，duang... ...炉石崩了
这类事故对久经战场的网易运维团队来说，没什么大不了，
应急容灾迅速启动，备用电源、服务器、网络逐一正常，终于，炉石跑了起来，大家继续准备过年。

15日，24小时后，运营同学发现，炉石有点小问题，用官方的说法是：不稳定，最终查到了数据库上，

DBA同学很快找到了这个小问题，不过，这位DBA同学比较细心，多查了一下。。。
结果，不查不知道，一查吓一跳，立即向上级汇报：
“X总，有几万个玩家数据有点乱”
“几万算个鸟，搞定它”
于是，DBA们继续埋头一阵猛敲键盘。。。
又24小时后。。。
“X总，数据丢了，回不来了”
“。。。算了吧，找个理由，封号”
“可是，然而，现在，封封封几十万，不太好吧。。。”
X总监终于意识到问题的严重性。
17日凌晨，1点0分0秒一过，立即停服，暴雪的外援、开发同学、Oracle专家一并招齐，准备奋战一夜
然，并卵，又30个小时后，所有的人都马着脸，所有的人都在想一个问题：
为什么？为什么？为什么是这时候？还有几天就发年终奖了。。。

网上已有不少分析、猜测文章，其中一位熟悉网易运维工作的网友的文章提到：
炉石中国，使用oracle数据库，节点数不少于4个，数据量10TB，
网易不但有高素质的运维团队，更有严格的运维、应急容灾制度。
加上各种各样的备份方式：全备、增量备份、网络备份、异地备份。。。
即使整个机房炸了，也能很快翻身再来。

然而，现实似乎却不是这样，现实是，网易重金准备的那一套又一套备份，关键时刻，统统成了鸟蛋。
下篇文章，我们将详细分析其中缘由。

2017.02 兰天 原创于成都