爐石傳說在必然有容災方案的情況下資料庫丟失數據的原因是什麼？

12-23

背景：爐石傳說在16號凌晨1點開始維護，在18號18點至19點之間宣布宣布備份出現問題。將數據回檔到14號。另外還有1個現象，維護之前有段時間爐石伺服器非常卡。
以下是爐石的官方聲明。

個人相信現在的容災方案只有極低的情況會出現問題。但是爐石這些出現問題了，希望有人能解答一下可能的情況或者一些技術細節導致的問題？當然更歡迎網易員工現身告訴我們是什麼原因（可能會讓網易員工很為難，抱歉）

可能性有很多，其實如果當事人不說誰也不可能猜對：
1、首先「斷電導致說」不是很靠譜，正常的容災設計必然是不怕斷電的，所以不一定有斷電，或者即使發生了斷電，也只是很小的一部分誘因，如此說是想推到天災上，讓玩家心理舒服一些。
2、其次「備份故障說」也不是很可信，至少不太會單純的備份資料庫故障，這種概率還是很低的。
所以基本上真實的信息都沒有暴露出來，可以猜測的情形就太多了。比如：
1、主庫故障同時從庫延遲
2、程序升級，但有重大邏輯錯誤，導致歷史無法恢復，寫入切到從庫之後，從庫數據也寫壞了
3、自研資料庫，有重大bug，導致主從數據全損壞
4、大家沒有感受到問題並且可以繼續玩耍，可能是資料庫層早已損壞，但主邏輯在內存中進行，玩家無法感知，但寫到資料庫的binlog早就不知道發生什麼了

凡是確定性猜出一個答案的都不可信

引一下我剛剛發的另一個答案

先說一下,我本是專業給運維狗挖坑的實施狗,後來又背叛了實施狗的陣營去做售前狗,專業給實施狗挖坑,在我前面還有專門給售前狗挖坑的銷售狗.

這個答案我發在了屎黃色論壇上，搬過來的時候又稍微改了一下
說結論：網易的運營團隊應當自掛東南枝刨腹謝罪

我爐石最好水平是用沒削弱的亡語獵打到了10級，然後就感覺智商被掏空了。最近事情多，基本就沒怎麼玩。
看了大家的討論，做了一下猜測：
14號生產系統故障，嘗試停機維護生產系統
到了15號生產系統不能上線，緊急啟用備用系統恢復運行
15號16號已備用系統運行
16號或者17號生產系統恢復正常
但是執行從備用系統到生產系統的反向數據同步時，出現故障，導致生產系統數據和備份系統數據同時損壞
執行數據回退，然後恢復到14號的確認無誤的數據，就是喜聞樂見的數據回檔了
--------------------------------------------------------------------------
作為乙方，給不少甲方設計了容災架構，也實施了不少。
但是，遇到問題真敢用容災架構的，有多少呢？基本沒有。
容災架構這東西，本質上是為了解決一個問題，活生生的引入了新的問題。
就拿數據來說，原來我把數據寫入一台伺服器就好，為了容災，我現在需要把數據寫到三台伺服器裡面去
看著很好，雞蛋分到三個籃子里
但是呢，這三個籃子里的雞蛋能孵出同一隻雞嗎？
我寫入第一台伺服器的資料庫，和寫入另外兩台資料庫的數據一樣嗎？
這又引入了數據驗證，我得想辦法確保這三台伺服器裡面的數據是一致的
而引入數據驗證以後，又帶來了系統性能下降的問題
總之做了容災以後，系統變得複雜而臃腫。
--------------------------------------------------------------------------
以上是技術層面的問題，然後還有人的問題。
運維工作的一大特點就是
無過便是功
系統安安穩穩的運行上一年，大家就可以ohyeah領年終獎然後明年升官發財換老婆了
所以，大家都不願意折騰
我寫過一些容災預案和容災演練方案，提交給甲方
然後甲方說，
你說的這些很好，可是我們不想這麼做
為啥呢？做一次實打實的容災演練風險太高了(朱日和這種軍演是由死亡指標的)
容災本來就是為了解決問題引入新的問題，本身是有一定的風險的
現在我的生產環境好好的，你讓我硬生生的從這個平穩的狀態遷移到一個陌生的狀態
我不敢，你能打保票你這容災架構萬無一失么？
就算你能，我也不想拿我的前途開玩笑：萬一出個玄學問題吧系統演練嗝屁了算誰的？
所以大家就不要開boss了,練練空跑位然後打打木樁,大家意思一下就好了.
悶聲發大財才是最吼的
這也就導致一群人眼高手低,真出了問題,大家就麻爪了.
金融業我記得有規定,一年必須做兩次容災演練,這個演練是真刀實槍的練還是點到為止的練,不好說.
於網易這個容災演練怎麼搞,咱們就真不清楚了.

反正就是:
有點天災做引子,引發了平時積累的人禍
最終導致了這樣的數據災難 ……咩~

不知道樓主有沒聽說過官方說法這麼個概念，

出了這麼大一件事，檯面上總得有一個說得過去的講法給大家一個交代吧，

這個說法是不是客觀的事實並不重要，

重要的是他要能被目標受眾群體所接受。

不是舅舅黨的肯定不知道這回網易發生了什麼，

但可能這個說法是幾種說法中最能為人所接受的。

至於真相是否如此，我們不知道，這也不重要（無從得知的隱情對於一般玩家也沒有實際意義）。

我覺得主要從幾方面去分析。
網易做遊戲的能力還是有目共睹的，所以說斷電造成數據損壞的問題。應該只是一個託詞。所以不應該以此作為數據不可恢復的理由。
一般在遊戲伺服器升級改造前，都必須備份資料庫以及關鍵日誌，這是常理。
就算升級出現了一些問題，比如最嚴重的數據污染問題，那也是可以回滾數據到停機維護那一刻的。
備份從技術到流程應該不存在什麼問題，恢復也是同樣的。
所以，最大的可能是，暴雪可能並沒有給予網易資料庫的備份許可權。
也就是說，網易的維護人員對數據本身不具備讀寫維護的許可權。
暴雪是一個很不錯的遊戲開發商，網易也是一樣的，從信任層面，暴雪肯定不想網易藉助著遊戲運營把自己的技術學去，所以必然會在某些方面對網易的運維有所保留。這是情理之中的事情。另外，就是暴雪的遊戲存儲格式，最好不要被運營商知曉，否則，運營商如果出現了人為調整數據的情況，可能會對整個遊戲的設計角度也會造成負面影響。
國內幾個代理大廠，基本上數據維護只是機器性能監控，有限的伺服器功能監控過程。所以，就算網易有很不錯的運維經驗，在爐石這個項目上可能也用不上。
這就是合作運營的達摩克里斯之劍，運營商相對大廠的弱勢地位，並不是技術問題。
當升級出現問題的時候，如果出現需要恢複數據的情況，可能性有兩個。
新版本的邏輯在某些方面對玩家數據進行了升級，但是在接下來的測試過程中，發現了邏輯BUG，升級後的數據"污染"了原始數據池，必須回滾原來的數據才可以。
這裡再做一個大膽的猜測，從日期來看，暴雪可能的備份策略是，每周五完整備份，其餘時間增量備份。
這裡就存在問題了，
當完整備份回檔後，再去追回當前的增量備份（比如1月18日是增量備份）。發現增量備份數據存在問題。無法覆蓋被污染的數據池。
這時候就要繼續往前尋找增量備份嘗試恢復。
但是這個增量備份可能存在一些問題，導致當前的增量備份完全不可用。
從而使得只能用全量備份替代。
那麼話再說回來，這個問題，很可能是暴雪增量備份的問題造成的。至於玩家說的網易40小時不回應的問題，很可能網易也和玩家一樣，完全不知道情況。因為備份還原的權力不在自己手裡，自己只能等，這事上，很可能也是一個無辜的背鍋者。
這次的問題，本質折射出來的是一個運營商和大廠代理之間的矛盾，對於數據管理權的矛盾。技術問題可能只是一個導致問題爆發的點。

很多時候只有當局者才清楚真正的情況，吃瓜群眾只能吃吃瓜子。因為做備份只是讀數據，即使有異常，似乎不應該導致數據損壞，如果業務系統本身也異常了，倒是可以解釋；另外一種可能是，主庫異常後，備庫升級為主庫也不正常。

停電只是託詞而已，現在給出的信息只有官方公告，到時候具體關注爐石哪個部門的被開除了就好唄（逃 @vczh

先是陰陽師，又是爐石
是不是年關了，運維忘記祭拜伺服器了

圖侵刪

不抖機靈了，回到正題

出現這種情況，網易官方給出的解釋是意外斷電事故。excuse me？斷電？現在家用電腦斷電了數據都能恢復過來，網易這麼大公司不太可能沒有備用電源。出現這種情況只能是伺服器，備份伺服器，電源，備用電源一起掛了，想想可能性並不大

第二，被黑客黑了。先不說網易這麼大公司養了那麼多技術人員，技術上安全性肯定是有一定保障的。就算是被黑了，黑客是想要送自己上天梯？還是想要幾張橙卡？拜託，被發現了這可是要判刑的。利益和風險不成比例，也不太可能。除非是熊孩子想搗蛋

第三，可愛的保安心疼電費拉了閘？多事的掃地阿姨看房間這麼熱，打開窗通了通風？門口的阿姨嫌噪音大拉了閘？進伺服器機房可是要經過層層檢查，穿無塵服才能進的。這種制度就可以解決的的事情，網易也不太可能在這兒栽跟頭

第四，出八阿哥了，還是大八阿哥。就像 @請叫我總工說的，關注網易負責爐石的部門哪個技術人員被fire掉了就行

總之管他哪出問題了呢，who care？反正我只關注出了這種事情，網易兌現補償承諾的時候會補償我幾張橙卡

最新消息！！

在網易宣布回檔之後，有玩家發帖表示自己開出的卡包顏色與之前的一模一樣。後面許多玩家紛紛跟帖表示自己遇到了同樣的情況，這麼一來《爐石》卡包機制的真相就浮出水面了。（轉自IT之家）

我就點到為止，大家可以在評論區隨意猜測

螞蟻金服 dba 強行回答一發。
@史強的回答大概說的是「本質折射出來的是一個運營商和大廠代理之間的矛盾，對於數據管理權的矛盾。」

但是網易做遊戲成熟，暴雪做遊戲也成熟。即使網易沒法使用自己的容災策略對於遊戲進行修復。暴雪難道沒有，暴雪提供給網易的升級方案中就不包含封裝好的備份策略？

所以我的觀點是，不管數據管理許可權在誰手裡，本次故障就是反應了數據備份沒有做好的技術問題。

首先從原因開始說。「斷電造成數據損壞」
機器掉電的確是一個比較嚴重的問題，有概率導致資料庫無法啟動。但是這個在目前主流的主從結構的資料庫方案下，是一個完全可以避免的問題。因為主庫從庫在不同機房下同時掉電的可能性幾乎不存在。
那麼接下來，如果主庫掉電了，從庫在不是最大保護模式下回丟失少量最新修改的數據。這個在數據持有方【不管是網易，或者是暴雪】應該是一個現有的方案，通過應用日誌，上下游系統找回這一部分少量的數據。

那麼我們看官方。「備份資料庫同樣出現故障」
現在遇到了一個更加嚴峻的問題，在主從結構的資料庫方案下，主庫從庫同時故障。數據徹底沒了？不會的，成熟的資料庫方案還有備份策略。
一般來說，資料庫會定期【比如說一周一次，一周兩次】進行全量備份到一個備份空間中。然後用更短的頻率進行增量備份【比如說4小時一次】。這樣即使主備庫同時出現問題。也可以使用一個空的機器進行將資料庫還原到任意一個時間點。

也就是說，在程序沒毛病的情況下。掉電導致回檔這個動作是說不過去的。

好了，剩下什麼可能呢？
1.數據因為程序bug 被污染了。【這個程序bug 可能是掉電觸發】
2.資料庫連著增量備份一起被刪除了。

那我們逐一看一下。
1.
數據因為程序bug 被污染了。導致資料庫一直處於一個不一致狀態，從14日出現這個bug ，到停機維護，然後程序猿嘗試通過數據訂正來企圖修復，後來發現需要訂正的數據量太多？或者訂正邏輯太複雜？最後放棄。由於bug 14日前沒有觸發，因此只能將數據回滾到14日的一致狀態。

2.
可能某一個人惡意進行資料庫的刪除，並且帶上將所有增量日誌，增量備份全部刪除掉。導致資料庫只能使用一個上一次的全備進行恢復。【但是這個惡意的人為什麼不把全備也刪除呢？】

也有可能是因為增量備份失誤，導致增量還原不可使用，所以只能恢復到這個全量備份的時間點。

斷電導致丟數據我是相信的，斷電導致丟失了幾天的數據我是不信的。
也許是機房被人給炸了吧。

有真正的原因, 只是不方便告訴你

遊戲伺服器出現數據問題，回檔是正常的處理手段。
遊戲數據的容災不比金融，電商，沒那麼複雜全面。
從網易的公告來看，這是一次非常嚴重的停電事故，導致數據損壞，遊戲數據的關鍵性很強，損壞一小部分，剩下的大部分幾乎也沒用。涉及用戶量可能非常大。斷電之後，網易重啟伺服器，以為玩家可以重新進入遊戲，但損壞的遊戲數據可能造成伺服器出現諸如死循環之類的情況，造成遊戲卡頓。網易此時才發現數據損壞，停機維護，沒想到數據量太多，而且備份資料庫也出了問題，修復無望，只好選擇回檔。

開發是開發，代理是代理
要是沒許可權，牛逼也干著急

該如何拯救本次《爐石傳說》數據回檔災難事故？

雖然這一整周都在加班到凌晨回去躺下就睡一局爐石都沒玩（@老闆），但是周末和我兒子一起可是打了好幾局天梯和競技場的啊喲喂。之前還是吃瓜群眾，前天晚上一上線看到日常竟然刷出3個術士任務心裡沾沾自喜，周末剛剛開出個新橙正好組了個新版卡拉贊宇宙術，進去一看麻蛋連卡組都沒了，更加想不起來到底新卡是哪一張了T.T。

作為從爐石公測就開始玩的爐石及20年暴雪全家桶自強老玩家（利益相關），對於此次[回檔事故](《爐石傳說》官方網站_暴雪首款免費休閑卡牌網遊) 的細節以及[補償方案](《爐石傳說》官方網站_暴雪首款免費休閑卡牌網遊)格外關注。各種網路服務包括在線遊戲碰到各種各樣的災難或者大小事故導致服務不可用問題屢見不鮮，但是對於暴雪/網易來說停服超過一天，之後數據紊亂開了又關，前後花了起碼三天以上時間花在嘗試數據恢復上，而且最後結論竟然是被迫所有遊戲數據**回檔**至災難發生之前，基本上是前所未見的。

到底發生了什麼？

不知道。官方公告只提及了「由於供電意外中斷的原因而產生故障，導致數據損壞」以及雪上加霜的「相關備份資料庫也出現故障」。對技術上的根本原因我也很好奇，不知道最終會不會公布RCA或者有內部爆料。朋友圈和知乎已經很熱，各方八卦雪片一般飛來看著就感覺很激動。比如這篇[《爐石傳說》大故障：不要以為你也可以倖免](《爐石傳說》大故障：不要以為你也可以倖免) 從暴雪DBA的JD以及Linkedin的CV入手，竟然推倒出了「O記資料庫RAC寫數據丟失無法完全恢復」的結論。外行看熱鬧，內行看門道，介於「外行」和「內行」之間的筆者，看到知乎上的討論[爐石傳說在必然有容災方案的情況下資料庫丟失數據的原因是什麼？](爐石傳說在必然有容災方案的情況下資料庫丟失數據的原因是什麼？ - 伺服器 - 知乎) 逐漸由刷成熱貼的趨勢，以及這麼多吸引人的關鍵字出現，實在忍不住怒答一波，聊聊看關於「機房斷電」，「數據丟失」，「容災切換」，「一致性」等火辣問題。

容災方案不給力？

從官方公布的信息來看，爐石的遊戲資料庫採用了比較主流且傳統的**主備模式**，備庫在不在**異地**不好說，但起碼並不是**多活**的。主資料庫掛了之後服務就已經中斷，一般情況下自動（或者把苦逼運維叫起來手動切換，希望他周六下午沒有在打守望先鋒）切換備庫，然後再手動、半自動、自動地回溯一下事務日誌把兩邊數據再同步一下就搞定了（說的好輕鬆，x翔技校畢業設計之資料庫管理系統既視感）。

我相信這四天時間夠從暴雪爸爸或O記資料庫總部調專家飛過來走兩圈了，然而事實上要麼備庫也碰到數據損壞，或者如許多討論所說，由於程序邏輯或者資料庫某些方面的不完備，切換至備庫之後產生了數據污染而又沒辦法自動清算，臟數據多到不可挽回的地步最後不得不一刀切，直接一夜回到解放前。

作為一款卡牌遊戲，最終花錢消災多補償一下玩家金卡金幣，過好大年之後也就知乎上還會有極客們討論討論容災技術，對於大部分玩家來說也就接受了。試想一下，如果這場災難發生在**關鍵金融場景業務**里，「回檔三天」的損失哪家機構可以承受？況且，暴雪網易的技術能力或許同一般普通規模的機構相比已經算是前列頂尖的了，一旦飛出黑天鵝，整個天空可能就黑了。

誰來拯救世界？

金融級分散式資料庫OceanBase資料庫

先作一段比較官方的敘述 -

OceanBase是國內首個擁有自主知識產權，並且在海量金融交易場景經過驗證的分散式資料庫。繼2015年交易系統100%在OceanBase落地，2016年進一步實現了性能與容災能力的突破，包含賬務系統在內的支付寶核心系統已全部運行在OceanBase之上，實現了對支付寶核心業務系統的全覆蓋，支撐了網商銀行的核心系統，經歷了多次「雙十一」的考驗，最終支持了2016年雙十一支付寶12萬筆/秒的峰值交易，形成了跨機房、跨區域部署的高可用架構，並在日常運行、應急演練和容災切換中發揮了重要作用。

當前市面上主要商業關係型資料庫本質上是集中式架構，其容量、性能和可靠性均依賴於單個或少量高性能伺服器與高可靠存儲的組合，但資料庫本身的性能、成本與可靠性依然是一個難點。拋開「去IOE」的政策口號不談，阿里及螞蟻的業務量和交易量每年都以將近翻倍的速度在增長，「雙十一」對全民來說是狂歡節，而對於技術人員來說是重要的「大考」，驅動著產品技術、整體架構乃至全套風控運維體系的升級和拓荒。

OceanBase自2010年起開始立項研發，目標就是打造金融級的分散式關係型資料庫。歷經將近七年，OceanBase對傳統資料庫架構進行了突破：

1. 高性能：資料庫的一個顯著特徵是總數量比較大，但每天變化(增刪改)的數據只是總數據量的很小一部分。因此OceanBase將數據劃分為基線數據和修改增量。基線數據即資料庫在某個時間點的一個快照，存放在每台OceanBase伺服器的硬碟中，修改增量即快照點之後的增刪改數據，相對比較小，通常存放在每台OceanBase伺服器的內存中。通過這種方式，使得增刪改操作基本都在內存中進行，從而獲得接近內存資料庫的事務處理性能；

2. 強一致：經典的主庫+備庫方式的資料庫，很難兼具高可用與強一致能力。為了解決這個問題，OceanBase使用多數據副本（&>=3）投票協議，對於每個寫事務，OceanBase只有在事務日誌（redo log）到達超過半數伺服器後，才應答客戶。這樣當少數伺服器（例如3台中的1台，或者5台中的2台）異常時，剩下的伺服器至少有一台有事務日誌，保證了資料庫不因為少數伺服器故障而導致數據丟失；

3. 高可用：關鍵業務的資料庫必須達到99.999%的可用性，伺服器故障、機房或網路故障都不能導致資料庫不可用。OceanBase通常由分布於多個機房（3個或以上）的機群組成，每個機群有完整數據，其中一個機群作為主庫對外提供讀寫服務，其餘機群作為備庫，接收主庫的事務日誌和回放日誌。當主庫故障時，剩下的機群會立刻自動發起投票選舉，選出新的主庫，新主庫從其他機群獲得可能存在的最新事務日誌並回放，完成後對外提供服務。

異地多活與容災: 單元化架構

關於OB的高可用這一點我們看到，一套典型的OceanBase部署通常來自三個甚至更多機房的計算和存儲機群。

「兩地三中心」是一種在金融系統中廣泛應用的跨數據中心擴展與跨地區容災部署模式，然而跨地區的備份中心通常不承載核心業務，不核心業務跨地區擴展能力較弱，而且容災時才拿出來應急的災備系統通常利用率很低，從成本考量很多災備系統的維護標準和性能甚至都無法達到生產環境的要求。而最終在容災能力上，由於災備系統冷備等待，容災時可用性低，切換風險較大。

似乎都戳到了此次爐石災難事件的痛點...

因此，螞蟻金服沒有選擇「兩地三中心」部署模式，而是實現了異地多活與容災模式。異地多活與容災架構的基礎是對系統進行單元化。每一個單元可以認為是一個縮小規模的、包含從接入網關、應用服務到數據存儲的全功能系統。每個單元負責一定比例的數據與用戶訪問。單元有以下關鍵特性：

1. 自包含性：比如用戶的一次賬戶充值交易，涉及到的所有計算與數據都在一個單元內完成；
2. 松耦合性：跨單元之間只能進行服務調用，不能直接訪問資料庫或其它存儲。對於一些必須跨單元的交易處理，比如分屬於兩個不同單元的用戶之間的轉賬交易，跨單元的服務調用次數儘可能少，在業務與用戶體驗允許的情況下盡量非同步處理。這樣，即使兩個單元之間相距上千公里，也可以容忍跨單元的訪問時延；
3. 故障獨立性：一個單元內的故障，不會傳播到其它單元；
4. 容災性：單元之間相互備份，確保每個單元在同城和異地都有可在故障期間進行接管的單元。數據在單元間的備份方式，我們以OceanBase提供的多地多中心強一致方案為主。

通過單元化架構，能夠將一個大規模系統分拆成許多個相對獨立的小規模系統，每一個單元系統可以部署到任何地區的數據中心，從而實現了靈活的異地多數據中心部署模式。系統的主要伸縮模式變成單元的增減，但一個單元內部的規模與複雜性不變，降低了系統的複雜性。單元之間的故障隔離，降低了軟硬體故障的影響面。「活」的單元和跨單元的快速切換能力，使同城異地的容災處理更為簡單高效。

目前，螞蟻金服的核心系統已經分布在上海、深圳、杭州等多個城市的多個數據中心，核心交易流量分布在各個數據中心，並且可以進行調度與切換。通過異地多活，系統可以在全國範圍內任意擴展，伺服器資源得到了充分利用，提升了系統應對地區級災難的能力。

說得好，你們很厲害，借我用用唄？

可以，沒問題，Money不夠，[借唄來湊](http://weibo.com/mayijiebei)。然而幾十萬人民幣並沒什麼用（幫兄弟部門打個廣告）。但是借了錢可以用來買雲服務，買資料庫啊！

OceanBase並不只是為了阿里及螞蟻自身業務而設計研發的，事實上其產品化之路在設計初期就已確立。在[阿里雲](OceanBase_ 雲資料庫_關係型資料庫_mysql-阿里雲)，OB已經向受邀企業開放。

如果您對螞蟻金服的技術和產品有興趣，請關注[螞蟻金融雲](螞蟻金融雲)。作為"互聯網推進器"，螞蟻金服將推動平台、數據和技術方面的能力全面對外開放，歷經十多年在金融領域的技術沉澱已經逐漸產品化、平台化，在2017年我們將服務更多生態夥伴。對螞蟻金服的異地多活產品和容災方案感興趣？還有分散式資料庫和分散式中間件？支付寶的移動框架能力和後台服務？智能雲客服「小螞達」？統統都有（前所未有認真臉）。

最近公關姐姐都很忙，不知道以上說了這麼多會不會給添麻煩。這邊工作雖然忙，但是充實啊，其實大多數時候一周只工作五天就夠了。搬了一周磚，馬上就能乘班車回滬帶娃打守望先鋒了，一直和小夥伴在魚塘游啊游，大神求帶Ranger#5711，我們可以一邊伸張正義拯救世界一邊聊聊雲計算。

更多參考：

- [螞蟻金服CTO程立：金融級分散式交易的技術路徑](螞蟻金服CTO程立：金融級分散式交易的技術路徑-博客-雲棲社區-阿里雲)
- [知乎話題：OceanBase](OceanBase - 熱門問答 - 知乎)
- [OceanBase之父，陽老師(正祥)的微博](http://weibo.com/kern0612)
- [Velocity China 2016分享 - OceanBase：螞蟻雙十一背後的關係資料庫](O"Reilly Velocity China 2016 Web 性能與運維大會)

不負責亂說：

其實之前爐石國服正在跑災備的測試，陰陽師出事了，爐石作為另一大吸金遊戲當然要穩定點，測試測試災備系統行不行啊,這樣過年期間有什麼問題可以放心用災備，其他事情可以來年再說。所以故障前大家覺得登錄很難，卡了一陣子，那是因為災備系統預熱程度不夠，容量比正常生產系統小。

但是災備系統卻有重大bug，導致跑災備的期間產生的數據一致性有問題。發現災備系統有問題立刻想回到生產，卻發現數據做了同步導致生產也有問題，想了很多辦法重建一致性，無效，只好回檔到災備前的備份。

這個損失粗略估計上億啊。

我猜是誤操作引起的數據污染，從爐石這幾天的不堪重負來看，貌似是備用環境。
然後備用環境的數據無法合併到主環境中，所以就乾脆從14日死掉，但後來恢復的主環境數據重新開始了。
備用環境的數據，整體合併到主環境比較困難，但不意味著可以謊報造假騙補償，要單獨查部分用戶數據，幹了啥，得到啥，還是可以的。

這個節點發生的事故，一般是年終獎沒發夠，內部人要弄你，什麼容災都是狗p。當然，年底這麼折騰一加班二加錢三補假，都到位了，一些莫名其妙的故障，自然而然就消失了。明年再見。

網易只是運營，遊戲伺服器資料庫伺服器架構具體都是暴雪設計的，這個鍋估計跟暴雪也有關係吧。

由於不知道爐石的系統架構，只能猜想。一般企業都有各種容災和備份，各種冷備熱備容錯分片。如果說14號出現了問題，理論上應該在15號16號搶救回來，可現在說要18號，那麼問題就嚴重了。13開始運營至今最多也就4年，硬體設備老花也沒這麼快。
1. 團隊技術不夠？我想這個問題應該不成立吧，畢竟網易這麼大一個公司，人才濟濟，即使這是個百萬小時的錯誤，那應該也是能快速定位並修復的bug。
2. 停電？網易給出的公告是停電？這裡想說的是，14號之後還是能陸續登入伺服器，說明計算節點和部分數據是正常的，至少用戶的關鍵數據是正常的，但是可能這個時候並未檢測出後來資料庫的錯誤，導致後續的錯誤。至於是什麼錯誤這裡不糾結，還是那個問題，停電也能很快恢復到原來的狀態，但是為什麼過了幾天還沒有修復？
3. 什麼？備份資料庫也出現問題？又遇到了萬年一遇的洪水了。這種情況也是有可能出現的。數據在歸檔備份時候把錯誤遷移到備份資料庫，導致備份資料庫也出錯。這是一個很牛逼的bug？要將數據恢復到14號以前，也就是說最終沒有搶救成功，這個錯誤實在是太厲害了。如果是人為，那藥丸了，下次還藥丸。
4. 還是在糾結這個修復時間太長的問題，想必原因不是那麼簡單。可能是維護人員的問題或者是開發時埋下的一個潛在的bug並且會影響到後續的運營，所以需要開會討論決定修復方案。我想後續應該關注爐石相關部門有哪些人被fire掉，原因就會慢慢顯露出來。
5. 坐等爐石賠我100金橙，還我天梯登頂！

以上

先總結官方說法，原因無非兩點：
1，資料庫意外斷電
2，備份資料庫失效

先說1，斷電。伺服器用的單電源？應該不會。雙電源也能斷電？只能說概率過低，算暴雪倒霉。退一步說真斷電了，斷電會造成停機沒錯，但是現在的資料庫伺服器必然有RAID，RAID卡上有基本都有電池。暴雪的伺服器不可能不用電池。這個電池存在的意義就是為了保障斷電後伺服器數據不丟失。按照正常情況，斷電後電池會持續為伺服器供電保障24小時甚至更多時間的數據不丟失，一但外部供電恢復，RAID卡電池保存的數據就會恢復。如果沒有恢復，那說明電池可能失效了。為什麼失效？有可能電池老化。老化為什麼沒有發現？暴雪是否有專業的維護人員定期對硬體性能進行監測？------------------當然，還有一種快閃記憶體式電容的解決方案可完美代替電池。具體原理我不太懂，應該是高速快閃記憶體技術，可用性遠高於電池，一般用於金融領域，不過代價就是成本過高，暴雪可能沒有採用。
再說2，備份失效。這個我就非常難以理解了。網易的聲明裡也是含糊其辭。一般來說，這種備份都是異地的，不受主伺服器機房網路環境影響。重要的業務更是會請專業的第三方公司來專門做容災。按照目前的情況，應該是暴雪自己運維了。那做備份的時候難道沒加監控嗎？或者說監控失效了？沒有人每天檢查嗎？？？？
感覺一個成熟的大公司不應該犯這種錯誤，好在「只」回檔到14號，別回到去年值得高興了。

講個笑話:斷電就會丟數據。

但是這個說法可以應付用戶的賠償要求，畢竟你也沒法去舉證。

就是不知道是刪庫跑路了還是被勒索咯~