62
技術社區[雲棲]
關於爐石傳說的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第一守則：備份重於一切
如果大家還記得我曾經寫下的DBA守則，沒有備份對於DBA來說將會是致命的，而如果沒有有效備份，那麼備份也隻能是心靈安慰。不論如何，備份至少可以給我們重來一次的機會，暴雪這一次最終救命的就是備份。雖然是回退到了14日。
既然備份這麼重要，國內數據庫的備份情況如何呢？雲和恩墨白求恩平台最近發布的《中國2016年Oracle數據庫運行現狀報告》顯示，有完整RMAN備份的數據庫不到20%，24%的數據庫甚至處於非歸檔模式下。
下圖來自報告數據，可以看到其實國內的數據庫的DG的使用率其實並不高，僅有21%：
Bethune 平台可以幫助大家檢查RMAN備份完整性，Dataguard同步及時性，假期來臨之前強烈推薦大家為數據庫做一次健康檢查。
關鍵節點是什麼？
回顧一下，數據庫帶病堅持工作，這是整個案例最核心的一個決策，也就是說，通過在線運行，同時修複問題（壞塊），向前走。
這也是一個艱難的決策，如此可以減少業務的中斷，但是麵臨的風險就是可能最終數據不一致，需要回退或者承受複雜的校驗工作。
大家可以想想我們麵臨這樣的工作會如何處置？
我就此訪問了浙江移動王曉征王總，他表達了他的觀點：
我覺得得按照業務特性，事先約定優先保A（可用性）還是保C（一致性），如果沒約定的話，如果我指揮，我會臨機進行決斷。
我非常讚同這一觀點，有了事先約定，應急處置時才能有準則，不出現重大偏頗。
要一致性還是連續性？
如前所述，每一個DBA團隊都應該有一個準繩，那就是在關鍵時刻，要保障一致性（準確性）還是連續性？
對於金融機構，毫無疑問，要保證數據庫的一致性，在遇到故障時，可以果斷中斷業務提供，進行數據恢複或者修複；
而對於互聯網業務等，可能連續性就更為重要，類似攜程的業務，中斷幾天的服務是不可想象的；
王曉征就此總結說，在運營商係統建設的過程中，最初覺得業務連續性最為重要，但是當這些問題已經被較好的解決之後，現在覺得數據的一致性變得更重要起來，所以不同係統在不同階段，就會有不同的取舍。
這是一個辯證的思考，也是運維發展到一定高度之後才能有的判斷。
為何不切災備？
關於這樣嚴重的事故，為何不切災備？
如前所述，從備份數據庫的一字之別，我猜測這個係統根本就沒有災備，所以無從切換，畢竟這隻是一款免費的遊戲，在官網首頁的顯示『《爐石傳說》官方網站_暴雪首款免費休閑卡牌網遊』。
對於災備的部署和切換，王曉征表示浙江移動內部是這樣的：
按業務重要度，實現不同保障級別。
一般係統：隻做數據備份，無高可用，無容災；
重要係統：數據備份，高可用，無容災；
核心係統：備份，高可用（部分含柔性可用），容災。
在實操層麵，一般係統基本絕跡，目前以核心和重要係統為主。
如果出現數據損壞，核心係統肯定切容災了，這種情況如果是硬件損壞或者刪除數據文件引起的問題，基本就搞定了；當然，最怕的就是誤操作或代碼bug搞出來的數據丟失，可能把容災端數據同時破壞，那就隻能通過備份來恢複啦。
由此可以看出，即便有了完備的災備環境，也很難防範所有問題，尤其是人為的誤操作，所謂『功夫再高，也怕菜刀』，一個誤刪除可能就級聯到所有的係統，再加上軟件BUG不可避免，除了災備，必然還要有可靠的備份來托底。
運維團隊怎麼配置？
大家還要思考一個問題，在處理複雜故障的時候，工作不能中斷，但是人不能持續運轉，在暴雪的這次事故中，從14日至18日，將近5天的時間，處理人員可能已經更替了幾輪，如何延續處理思路、執行正確決策、保持核心戰鬥力，這也是運維要思考的重要因素。
如何幸存於類似事故？
好吧，我們談一談如何避免陷入這樣的困境？以下是我們的一些思路，與大家商榷。
首先，要有完善、有效的備份和容災機製。誠然很多企業都有了一整套的備份、容災機製，但是這套備份機製能否真實奏效是需要檢驗的。我接觸過某大型企業，投入巨資興建的災備中心，從未正式切換過，這樣的災備在故障來臨時也很難有人拍板去進行切換，所以備份的有效、容災手段的有效是必須確保的。注意，備份的恢複速度必須足夠的考慮到，磁帶的低效備份關鍵時刻會害死人。
其次，要有完善的故障處理策略和流程。對於不同係統，在關鍵時刻要優先確保什麼，是要訂立規則的，有了規則才能照章辦事，不走錯方向，不無辜背鍋。幾年前某國內金融係統出現數據壞塊，同樣選擇了帶病修複，最終沒能解決問題，同樣選擇了回檔承擔了數據損失。
再次，要有端到端融會貫通的應急機製。也就是說不僅僅技術上具備容災應急的響應方案，從業務端同樣要有對應的預案，以便應急時同步處理，區別對待。很多時候，有了業務上的應急、降級服務方案，技術層麵的處理就能夠從容許多。
最後，要有能夠快速協同的團隊資源。很多時候嚴重的故障，需要較大規模的專業團隊協作處理，原廠商和第三方在其中都承載著重要的角色，所以關鍵時刻，要能夠獲得內外部快速及時的支持，尤其是在綿延數天的高強度工作中。
對於事後的補償，19日暴雪已經給出了反饋，第一條就是“隻要曾經在2017年1月18日18點之前登錄過國服玩家，均可獲得與25卡牌包等值的補償”，越來越覺得，這次“營銷”是很成功的。
感謝王曉征提供觀點，歡迎大家留言回複您的觀點，以上內容純屬猜測，猜對了也別告訴我。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 17:03:28