看到我這标題，千萬别以為我是故意為了吸引你的眼球，而是官方這麼說的哦：
這裡用到個詞—“回檔”，今天第一次聽說，最開始不了解啥意思，接着恍然大悟，不就是oracle 9i開始提供的新特性flashback麼！
你的朋友圈是不是也被刷屏了
昨天大概6點左右開始，我的朋友圈被刷屏了。
結合貼吧的一些留言，簡單回顧下大體過程：
1月14日15:20開始，資料庫由于供電異常中斷，資料損壞。
接着資料庫帶病工作2天。
1月16日淩晨開始進行修複維護。
1月17日下午，維護時間超過30小時，資料“修複”失敗，丢失資料超過30%，接着發出上述故障公告。
接着在多玩網站，一位自稱曾是“天下3”的維護者透露：
“你們以為資料都在伺服器裡？ 伺服器隻有硬體而已，硬碟資料13年-16年都是用的dell的磁盤陣列伺服器，而且是雙機熱備+異地容災，我這台資料丢了，我另一台會有克隆的相同的資料。就算廣州整個機房炸了，我上海機房異地也會有一台克隆的資料。
是以資料丢了，資料丢了30%什麼，大家就不要信了。
我在做天下3運維的時候也遇到過n種問題，不過都被總監、經理他們這些人帶着解決了。
可以說，就算來個10歲的小朋友，會動電腦滑鼠看得懂字，按照流程都不會出問題。一個團隊4個人，一個經理， 5個人同時犯錯？怎麼可能因為操作失誤就丢30%資料？”
同時，另一位網友号稱是内部消息，說是伺服器人為操作失誤。
嗯。其實你肯定看不到真實原因了，我隻是在告訴你架構和維護的基本知識。
我們從幾個不同的角度來解讀這個問題。
老楊是運維界的老司機，而據了解涉及的庫可能是oracle，我們來看看從這個角度來分析，問題可能在哪些地方。
同時有雙機熱備+異地容災，當然還應該有備份（哦，公告裡說，備份資料也損壞了！），資料還是丢了30%，這又中了墨菲定律！
那麼這個架構的問題在哪裡？
從我的經驗來看，這本身的架構有問題：
備份幾乎應該是假的！別懵，難道你家的所有資料庫最近3個月做過恢複演練麼？沒有做過，就有可能是假的！書到用時方恨少，資料要恢複時方恨沒有做演練！
其次，公告中說，是由于機房掉電導緻的故障。說得非常合理，我們經常遇到這樣的故障。猶記得，14年初，某營運商春節前夕，機房掉電，存儲拉不起來，主機起不來，資料庫起不來…..但是，但是，但是，因為有我們，整個故障零資料丢失，連夜調配專家把系統給修好了，天亮睜開眼睛，對于廣大吃瓜群衆來說，是無感覺的。
絕大部分的供電突然中斷，導緻的資料庫故障，都是相對容易能解決的。極端情況下，可能要丢一部分資料，但絕不至于30%。
那麼，唯一的可能原因，就是人為誤操作了！
我在貼吧看到，這個故障的影響，貌似沒那麼大，大多數是說這幾天打了多少關，充了幾百塊錢……
爐石傳說這樣的資料庫架構，在銀行、在營運商、在保險公司，并不少見。但是，如果這樣的30%資料丢失，在任何一個這樣的公司裡，恐怕不隻是dba、運維負責人會沒有年終獎，公司總裁都得下課吧！
而建榮猜測這個資料庫是mysql的，會從遊戲架構和基本的備份恢複對問題做一些解讀，僅供參考，當然反思的更多是問題所帶給我們的啟示。
首先專門下載下傳這個遊戲看了下，它分為pc版，iphone和android版，換句話說，是端遊（pc版下載下傳需要250mb左右）和手遊并存的情況。可以間接說明這款遊戲還是蠻火爆的。
上面的方式表明在遊戲中存在着大量的gs(game server)，玩家的資料是存放在gs中的，比如你去玩遊戲時，登入的某個服，可能就是在某個具體的gs上，而各個gs之間的資訊一般是不會共享的，而且基本上表結構資訊是相同的，是以也就直接實作了分庫分表的方式，這種方式采用mysql就是一件很自然的事情。而接入子產品和更多的賬号，充值資訊等，可能會有大平台或者是相對獨立的資料庫。
是以描述中說的30%的資料，要不就是某個服的資料丢失，或者是丢失了指定時間點的資料庫日志，估且按照30%來算。而且再說一句，那就是遊戲裡的cache其實做得已經很不錯了，當機的時間不是很長，其實對于資料庫來說影響不是很大，因為玩家的資料都在緩存裡，如果耽誤太長時間，資料落盤的時候才會有直接影響。
有一點需要說明，其實運維行業是很難杜絕丢資料的，不管你接受還是反對。
我聽過很多行業的運維同仁達成的一個基本觀點就是丢資料是可以接受的，但是資料不能亂，資料丢了可以補啊，但是亂了，這個複雜度就會提高幾個量級。因為是個虛拟的世界，這個場景相對特殊一些，是以遊戲行業裡有一種說法就是回檔，把所有的資料恢複到一個指定的時間點，而給玩家一些補償。這個過程會給遊戲營運來說，相對也會好一些，畢竟一個爆款的遊戲每個小時的流水是相當不錯的，你說讓長達幾十個小時去恢複，換做誰都不可以接受。說句實在的，有些核心業務當機個把小時都要被罵得狗血淋頭，幾十個小時，那肯定是有一些更複雜的原因。
對于資料恢複，我聽過很多oracle資料恢複場景，資料庫是直接無法open了，無法open就意味着完全不可用，一個基本要求就是把資料庫至少拉起來，而資料恢複是在這個基礎之上的事情，至于是不是零資料丢失，這個就不太肯定了。而mysql是沒有這種狀态的嚴格标示的，是以恢複也是在這個基準之上。哪一類場景比較麻煩呢，那就是人為錯誤，誤删資料等。這個恢複起來非常複雜，而且退一步說，哪怕資料現在修複了，你能肯定資料100%沒問題？是以從營運和穩定安全的角度來說，其實出現這種故障，如果增量恢複有問題，應急政策還是更傾向于回檔。
遊戲行業相對來說還是挺激進的，很多遊戲都會大規模開始部署雲服務（雲伺服器或者rds），如果大家用過一些雲廠商的rds就會知道，連從庫都不用搭建了，是以備份恢複的事情是肯定不需要自己操心的，一旦出了問題，恢複是相對來說較為容易的事情，而如果有了問題，那背鍋俠也不是營運方而是雲廠商了。而如果使用雲伺服器，除非有什麼特殊的場景，否則還不如直接用rds友善和實惠。而這裡就會有一個折中，那就是性能和網絡，還有安全，是以有些對于性能要求高的遊戲可能會更側重于高配的伺服器，或者高配的rds。從這個案例的描述來看，感覺不像是使用了雲服務。
這裡我想到幾個不是邏輯的邏輯，有時候是糊弄自己，有時候是被糊弄。做運維其實心裡也苦。
資料量太大，是以不做備份。資料重要嗎，很重要，那為什麼沒備份？
系統也很穩定，要備庫幹什麼，就是個擺設，多浪費，縮減一下預算吧。
伺服器現在已經過保了，得換一台新機器了。那現在伺服器不是好好的嗎？
即使你的資料庫架構有問題，也過了年後再說吧！
但你至少得在春節前做好這幾件事：
對你的系統做一次深入的大排查。
及時修正排查到的隐患。
抓緊完成核心系統恢複演練。（非核心的估計來不及了。真出問題，你就認了吧！）
封網！不必要的變更，統統禁止。
不要存在僥幸心理，墨菲定律就在我們身邊。
原文釋出時間為：2017-01-19
本文來自雲栖社群合作夥伴dbaplus