115
爐石傳說罕見數據庫事故！丟失30%數據，疑似誤操作？
引言
看到我這標題，千萬別以為我是故意為了吸引你的眼球，而是官方這麼說的哦：
這裏用到個詞—“回檔”，今天第一次聽說，最開始不理解啥意思，接著恍然大悟，不就是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個月做過恢複演練麼？沒有做過，就有可能是假的！書到用時方恨少，數據要恢複時方恨沒有做演練！
-
雙機熱備（或者是RAC）+異地容災，對於一個想當然的情況來說，是可以的。但是，在16年的Salesforce文章《Salesforce數據庫故障丟失5小時數據，僅僅是個案？》中我就提過，你還是圖樣圖森破了。你至少應該再搭建個DG，延時應用。如果你真做了就不可能丟失30%數據！
其次，公告中說，是由於機房掉電導致的故障。說得非常合理，我們經常遇到這樣的故障。猶記得，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
最後更新：2017-05-15 17:33:07