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

王楠w_n

獲獎公布：最佳優(yōu)勝獎：michael1983
精彩回復(fù)：lsstarboy    forgaoqiang    o楓葉o飄零
請以上獲獎人員在4月20日前將姓名、電話、郵箱、公司、職務(wù)、快遞地址站短給hyukhae079408，以便盡快給大家發(fā)放禮品。

導(dǎo)語：
昨天下午突然看到，《爐石傳說》游戲數(shù)據(jù)庫發(fā)生宕機并引發(fā)數(shù)據(jù)丟失事故的新聞。剛看到時，滿滿的不可思議。暴雪啊，網(wǎng)易啊。

都是很牛叉的公司。他們出的游戲也很受大家歡迎。

當(dāng)看到，第一時間著手搶修，重啟服務(wù)器，并嘗試數(shù)據(jù)恢復(fù)時，我的想法是他們的高可用方案呢？為什么不馬上切換？

當(dāng)看到相關(guān)備份數(shù)據(jù)庫也出現(xiàn)故障時，就更無語了。其實這樣的事情在我們的客戶每年都會遇到很多。前不久就有一個醫(yī)院， 數(shù)據(jù)庫和備份都同時損壞，而且沒有高可用的方案。

雖然最終幫他們修復(fù)了好數(shù)據(jù)庫，但還是丟失部分數(shù)據(jù)，而且中間1天時間，業(yè)務(wù)都是手動操作，嚴(yán)重影響業(yè)務(wù)。

對于爐石這樣的大公司，對應(yīng)的方案應(yīng)該是做得很全的，本次事故也可能是有其他的原因。

至于事故的具體原因，大家也可以暢所欲言，批評指正！


那么，

從您的角度，分析此次問題存在的原因是？是官方聲稱的數(shù)據(jù)庫由于供電意外中斷，丟失，還是另有隱情？


活動時間：1月20日—2月20日


活動獎勵：

本期活動，我們將特設(shè)1個最佳優(yōu)勝獎，送DTCC2017大會門票一張。

同時，我們將會選取3個精彩回復(fù)，各送社區(qū)15周年限量版男士商務(wù)晴雨傘一把。

DTCC 2017 來啦！

隨著云計算和大數(shù)據(jù)時代的來臨，數(shù)據(jù)正在以前所未有的速度成為各個領(lǐng)域價值創(chuàng)造的核心驅(qū)動力。

在此背景下，國內(nèi)最受關(guān)注的數(shù)據(jù)庫技術(shù)盛會——2017第八屆中國數(shù)據(jù)庫技術(shù)大會（DTCC2017）將于2017年5月11-13日如約而至。本屆大會以“數(shù)據(jù)驅(qū)動•價值發(fā)現(xiàn)”為主題，匯集來自互聯(lián)網(wǎng)、電子商務(wù)、金融、電信、政府、行業(yè)協(xié)會等20多個領(lǐng)域的120多位技術(shù)專家，共同探討Oracle、MySQL、NoSQL、云端數(shù)據(jù)庫、智能數(shù)據(jù)平臺、區(qū)塊鏈、數(shù)據(jù)可視化、深度學(xué)習(xí)等領(lǐng)域的前瞻性熱點話題與技術(shù)。大會共設(shè)定2大主場和20個技術(shù)專場，將吸引5000多名IT人士參會，為數(shù)據(jù)庫人群、大數(shù)據(jù)從業(yè)人員、廣大互聯(lián)網(wǎng)人士及行業(yè)相關(guān)人士提供最具價值的交流平臺。



官網(wǎng)鏈接：http://dtcc.it168.com/
購票鏈接：http://dtcc.it168.com/goupiao.html

歡迎掃碼關(guān)注DTCC官方微信，獲取最新信息！

670260542li

額。。。第一次奪得第一位！哈哈�。⌒〖�動！針對這次游戲數(shù)據(jù)庫出問題這件事情看來，我覺得其實沒什么復(fù)雜的，在一個環(huán)境當(dāng)中，再牛叉的高可用也變成了低可用，除非做到異地備份與多可用區(qū)的高可用。。。要不然，停電一次就是一次災(zāi)難！��！

王楠w_n

回復(fù) 2# 670260542li

牛

o楓葉o飄零

先占個位置，這個問題場景 我遇到過  
我說說在上家公司的情況

項目托管在客戶找第三方的機房。然后有整機房停電的想象。

因此我們做數(shù)據(jù)庫(mysql)時，就做了 2主1從       主（機房1） 主（機房2） 從（機房1或者2）

這架構(gòu)只能保證當(dāng)其中一個機房出問題時，另外1個數(shù)據(jù)庫能用。

但是這個架構(gòu)有個缺陷就是無法做高可用，所以在實際過程中有點蛋疼。

有一次出現(xiàn)了一個意外情況， 有一個機房突然斷電了，然后就發(fā)現(xiàn)數(shù)據(jù)庫連接不上了，然后準(zhǔn)備手動切換到另外一個機房上時，發(fā)現(xiàn)mysql重啟起不來了，再然后死活無法啟動mysql了。

過了30分鐘，那個機房來電了，然后準(zhǔn)備啟動mysql，一樣也無法啟動了   再檢查從庫，出現(xiàn)一樣的問題。  這時我開始絕望了。 （數(shù)據(jù)量太大，有1.7T  沒有定期做完備）

最后的解決方法。，把mysql里面的ibdata1和.frm文件copy到另外一個新數(shù)據(jù)庫，可以啟動了 ，然后準(zhǔn)備用mysqldump，無法mysqldump，我頓時無語。 最后只能用select導(dǎo)出數(shù)據(jù)，然后再還原了。。。。。

但是還是損失了幾個小時的數(shù)據(jù)
最后發(fā)現(xiàn)由于停電把那個單庫的.frm文件損壞了。。。而且所有主備機上的那個文件都損壞了。。

因此對于IT這種不是完全可控的來說，大黃易的情況我也能理解。不過對于大黃易來說，這次損失確實慘重

renxiao2003

我覺得完全有可能。比如人為操作（不是故意的），或者外界因素，如電力，空調(diào)通風(fēng)等都可能同時造成服務(wù)器和熱備機同時出現(xiàn)問題。除非將主機和備份機放在不同的地方，比如至少不在同一個房間，當(dāng)然最好是在兩個不同的樓中（在不同的區(qū)域），停電一般是一片區(qū)一片區(qū)停的，不可能整個城市停電。

denisdu

供電中斷，相信嗎？機房的電池不是一塊兩塊的，是很多的，UPS也有兩套主備，再說還有柴油發(fā)電機呢，備電設(shè)施全壞誰信��？市電要是停的話也會提前告知，就是人為操作導(dǎo)致的，凡是經(jīng)歷過的運維人員都會知道的有時候就是神志不清的輸入了rm -rf / ,天知道我為什么要敲這條命令且行且珍惜，建議尤其是DBA，最好買本《刪庫跑路指南》

hellioncu

說是1.14 15:20停電導(dǎo)致數(shù)據(jù)庫損壞，備份也壞無法恢復(fù)，后面又說回檔到1.14 15:20的狀態(tài)，那就是說停電并沒有導(dǎo)致數(shù)據(jù)庫損壞，這不自相矛盾么？公告寫錯的概率不大吧，我覺得是隱瞞了實情。

fenyun689

肯定是不愿意投錢。高可用方案只是做個樣子，給外面看呢。沒有真正去做。
沒想過真的會出意想不到的情況。
像銀行，電信等行業(yè)做的還可以。

cjfeii

難道真是誤操作

cjfeii

可能性1：
這是一起運維人員操作失誤與玩忽職守的責(zé)任事故。
可能性2：
發(fā)生小故障不愿停機維護，帶病運行導(dǎo)致事故擴大。