《炉石传说》数据库灾难剖析之2--为什么备份成了鸟蛋（原创）

前文我们说到，网易像宝一样藏着备份数据，当有一天想拿出来晒晒时，却发现，统统变成了鸟蛋。

通常，当我们的系统宕机，运维同学首先会试着重新启动，然后简单测试下系统能否正常运行。

这个测试不可能全面，运营在催、玩家在骂、肚子在叫，赶快跑起来，皆大欢喜。

不过，表面上看来的一切正常，暗里，却可能留下了一颗地雷。这颗地雷是怎么埋的？

有可能是宕机，正好破坏了一小块数据，很关键的一小块数据；也有可能是运维同学手贱、犯晕加健忘；也有可能是代码里本来就有没测出来的BUG，就等着踩爆。

总之，网易很不幸，当大家正欢欢喜喜准备过年时，那一小块坏数据正悄悄扩散。直到很长时间后，才被意外发现。

运营开始封号，运维开始修复，但此时的数据库，正以每小时数百万条的速度发生着变动，运维同学啪啪啪的敲着键盘，可坏数据就像瘟疫一样，四处扩散。

最终，运营不得不同意停服，各方使出最后的洪荒之力，但还是无力回天。

“启用备份”，这个金宝卵终于有机会拿出来炫一下。可真要用的时候，却左右为难。

恢复备份，就是回档，回到什么时候呢？10小时前？里面已经坏了不少；20小时前？还是不行；四天前？？？于是，数百万玩家的肉就这样割掉了。。。

四天前，当系统投入运营的一瞬间，我们重金留下的备份，就像投入锅里的蛋，熟了。而你，却还指望着它能孵出金凤凰？

事实上，原因远不止备份一个，本人在此明确指出《炉石传说》数据库灾难事故的多层次原因:   

    1.因意外事故导致数据小范围损坏；

    2.因未及时监测到坏数据导致混乱扩大；

    3.因运营不愿停服而使故障继续扩大；

    4.因数据在线修复难度太大修复失败；

    5.因准备不足导致离线修复也失败；

    6.最后，因无法区分备份中的好数据坏数据而全部回档。

后文，我们将继续刨根问底，逐一分析这六方问题，并寻求解决之道。

2017.02 兰天 原创于成都