【大話IT】由爐石傳說數(shù)據(jù)庫事故說起！你的數(shù)據(jù)如何備份？(獲獎名單已公布)

action08

社區(qū)評論不少，有人吼163做事做人要多學學暴雪大神
也有人直接吼大神下次出事情，請?zhí)崆巴ㄖ�（領(lǐng)取補償）

qingduo04

先說說官方給的電力問題的解釋

如果歸因在電力問題，那可以解釋過去，不過也存在一些問題，先說說解釋的問題

1.  電力故障是機房中最嚴重的故障問題，不僅僅涉及到數(shù)據(jù)庫，同時涉及到其他的業(yè)務，比如前臺訪問均出現(xiàn)問題，并且由于機房電力故障，對于正在高速讀寫的存儲來說災難性比較大，
這也就造成了，數(shù)據(jù)可能會丟失。
     舉例：我們機房原來發(fā)生過一個機柜出現(xiàn)斷電，造成數(shù)據(jù)庫對應的部分數(shù)據(jù)變成不可讀，好在是OLAP系統(tǒng)，數(shù)據(jù)可以再生成，影響不大。

2.  由于異常斷電，可能災備會出現(xiàn)問題，數(shù)據(jù)沒有及時同步過去，造成數(shù)據(jù)丟失，同時如果沒有災備，數(shù)據(jù)絕對就會丟失了，但是災備和生產(chǎn)是在一個機房么？ 這是需要考慮的？


除官方給的說明外，我覺得也有幾方面造成這樣的問題
1. 數(shù)據(jù)被誤操作，包含災備的數(shù)據(jù)，同時被誤操作。
2. 數(shù)據(jù)容災或者備份不到位，真正要啟動備份，發(fā)現(xiàn)根本不可行。
...................

lsstarboy

１、斷電就造成這么大傷害，這系統(tǒng)也應該背點鍋才對，包括操作系統(tǒng)、文件系統(tǒng)、數(shù)據(jù)庫系統(tǒng)，斷電可以出現(xiàn)異常，丟部分數(shù)據(jù)也是正常的，但是大批量丟失數(shù)據(jù)肯定是不正常的。

２、備份和主庫同時損壞，這種機率應該比彩票中獎還小，除非……有人為因素。

３、備份和主庫放在同一機房？這就不僅僅是技術(shù)問題了，領(lǐng)導就根本不拿數(shù)據(jù)當財富！

４、對于在線的熱備，主庫壞了，備份庫應該馬上能接手，但是如果主庫被黑了，或者主庫出錯了，那么熱備的庫肯定也是完蛋——是不是我想多了？不針對任何人哦！

５、從網(wǎng)易發(fā)的聲明中有點困惑，回滾的時間為出現(xiàn)問題的時間，然后說有人需要重新練，也就是說，數(shù)據(jù)庫故障后，游戲仍在繼續(xù)，但是數(shù)據(jù)沒法入庫了，那么結(jié)論就是：游戲數(shù)據(jù)不是實時入庫，并且數(shù)據(jù)緩存沒有持久化的功能——這種情況跟現(xiàn)在的技術(shù)好像不點不搭，我一直認為這方面的技術(shù)已經(jīng)比較成熟了。

forgaoqiang

禍不單行 不管是gitlab的五層備份 還是各家公司的各種吹的牛，在事故面前都是紙老虎

先解讀下官方說明：
我們看到這個破殼而出的Robot甚至牛X，故障發(fā)生在1月14日（東八區(qū)）的下午3點20分，當時也不是什么陰謀就給數(shù)據(jù)庫供電的電沒了，然后數(shù)據(jù)就損壞了。
當時維護人員就上去搞，發(fā)現(xiàn)不管是二進制日志還是啥的都不好使，主數(shù)據(jù)庫宣告正式陣亡。
于是團隊找了備份君頂上去，不知道什么原因備份君也不給力，一起跟著歇菜了（比較奇怪，備份君為啥會也跟著歇菜呢）
沒辦法只能繼續(xù)回溯，找更早的備份君頂上去。

于是和當年騰訊QQ一樣做了個艱難的決定，把大家的數(shù)據(jù)都丟了吧，回爐重造（畢竟是爐石嘛，可以重頭練）
當然大家的損失我們還是要補償?shù)�，比如每個人添加點數(shù)據(jù)進去（要真金白銀那是肯定不行的，當然我們回頭開個會決定下給多少）





故事情節(jié)大概就是上面說的吧，于是問題就來了：

爐石傳說，這可是爐石傳說啊，直播都排名前幾的超級火的游戲，那嘩嘩的氪金玩家的銀子那是流淌個不停，運維肯定是最頂尖的，服務器和設備也是最好的，當然供電和空調(diào)肯定也是必備的，只是出了點問題：
首先電源不知道為什么沒了（如果真是電源沒了的話），物理安全存在問題。
當然不就是沒電了么，上電后繼續(xù)跑唄，額 跑不動了，系統(tǒng)損壞了，已經(jīng)和windows和linux還是unix無關(guān)了，總之數(shù)據(jù)是不對了
當然這都是小事，旁邊不還是有個slave等著么，他整天想著翻身把歌唱，只是繼續(xù)咸魚了
先不說主服務器那么容易歇菜，問題是備份服務器為什么也會跟著一起歇菜，不是沒做好就是有人做的太好

總之吧，這事就是個教訓，肯定沒有檢查過備份君的情況，估計他一直沒有好好干活

laputa73

這類大型游戲，估計數(shù)據(jù)庫都是集群，做了切片處理。
停電之后數(shù)據(jù)庫損壞，這個可以理解，主備庫可能在同機房。電信的idc機房都時不時來一次全區(qū)域掉電。游戲數(shù)據(jù)庫，估計也不可能做到異地容災。
只能使用之前備份的鏡像+停電前的事務日志進行恢復。
如果等到恢復之后再開服，應該問題不大。
但是如果帶病運行，不同服務器間的數(shù)據(jù)一致性就會被破壞，無法恢復。

C.O.B

1.首先確認通過此類事故，用戶關(guān)鍵業(yè)務的RTO、RPO要求是多少？
2.其次需要確認用戶的環(huán)境信息，什么數(shù)據(jù)庫，版本信息，運行在什么平臺，物理機還是虛擬機？
了解了這些大致狀況，才能給用戶推薦合適的方案。當然，方案也是基于預算的。
備份方案的RTO和RPO畢竟是有限的，滿足不了的情況下就應該考慮關(guān)鍵業(yè)務的本地雙活了，那就是另外的話題了。

fengzhanhai

回復 1# 王楠w_n
主題錯了

Fl_wolf

個人覺得，他們給出的是備份數(shù)據(jù)不能恢復
這個是有可能的，但是有數(shù)據(jù)庫備份權(quán)限的用戶全備不可能不檢查的吧
有可能只備份了數(shù)據(jù)結(jié)構(gòu)？ 還是什么，也有可能備份的管理員換了個人，導致出了問題。
這些很難說，也有可能是惡意刪除。的原因，說不準。
不過還是警醒運維人員，數(shù)據(jù)要多備份，每個月要查看一次備份數(shù)據(jù)是否正常。

forgaoqiang

感覺備份可能是做了 但是至于能不能用 只能在主數(shù)據(jù)不能用的時候才知道了

七彩山楂樹

hellioncu 發(fā)表于 2017-01-23 09:39
說是1.14 15:20停電導致數(shù)據(jù)庫損壞，備份也壞無法恢復，后面又說回檔到1.14 15:20的狀態(tài)，那就是說停電并沒 ...

我也留意了