下廚房6月26日數據丟失事故總結
Posted by破冰on 2013-7-8 9:39 Monday
在6月26日凌晨12點左右,我們在做線上數據庫的備庫時,誤將線上數據庫分區上的所有文件刪除。丟失的數據時間段爲4月23日至6月25日兩個月,在經過7天的努力後,恢復了99%以上的數據。(具體見下面的統計)。
下面把整個事故過程記錄下來,令關心本次技術事故的人們知曉。
一.事故隱患
現在回顧,事故隱患在4月23日之後就已經存在。
我們線上數據庫使用的是MySQL,在4月23日之前,我們對線上數據庫主節點有三類備份。一是有一個獨立的數據庫從節點來備份,與線上服務器保持數據的實時同步,需要時可切換作線上使用。二是會定期把整個數據庫dump成sql文件來備份,一天保存一次,備份的來源是數據庫從節點。三是主節點開啓有binlog,默認是保存十天的日誌,十天內有任何事故可以從日誌裏完整恢復全部數據。這三個備份分別存放在兩臺不同的物理機,三個不同的分區上,是當時想到的最安全的方式。
4月23日,我們把數據庫主節點遷移到一臺新的物理機上,並把版本升級到5.5。由於版本和配置的問題,原來的從節點並不能直接使用。而一天一次的備份來源是從節點(備份主節點會令網站和手機app有1小時左右的卡頓),這個備份方式也就停止了更新。只有最後一個binlog還在運行。數據庫遷移之後應用服務器存在一些性能問題需要投入時間,包括修復 MySQL5.5版本和原代碼的兼容,以及把應用服務器從gunicorn換成uwsgi,之後又陸續有一些開發任務,以致重新啓用備份節點的工作一再拖延。
我們對數據庫遷移工作的管理存在失誤,是造成事故的根本原因。沒有完成數據庫備份節點,遷移工作就並沒有結束。我們技術團隊的所有人對這個事故都負有責任,這個隱患在兩個月裏都可能被發現,每個人都有可能提出這個工作的高優先級。也都可能提出相應的彌補工作來保證數據安全,比如在啓用從節點前延長二進制日誌的保存時間等。是我們的工作失誤使數據庫成爲系統最脆弱的環節,經受不住偶然事故的衝擊。
二.事故發生過程
6月26日凌晨12點左右,我們開始重新建立備份節點的工作,需要把原來的從節點刪除,重新安裝,所以先使用了rm -f方式刪除備份節點分區上的所有文件。
5分鐘後,發現剛纔刪除的是數據庫主節點的分區,爲防止硬盤繼續寫入,就馬上把mysql進程停止了。所有技術人員開始應急處理。一是把整個分區dd成鏡像,準備做將來硬盤恢復的備份。二是把memcache裏的數據dump出來,以備可能的恢復。三是重新啓用原來的從數據庫,由於數據時間只到4月23日,需要調整近兩月表結構變更,讓最新的代碼可以跑起來。
當天的應急工作至凌晨4點,服務器都恢復訪問,但數據停留在4月23日。
在整個應急過程中,部分是緊張,部分是溝通上存在誤解,還是出現了失誤。當配置從數據庫的技術人員完成之後,重啓了服務器和memcache,恢復了正常訪問。但是做memcache導出工作的技術人員還沒有完成,所以最終能從memcache裏得到的那部分數據只有一半左右。
事後從沃趣科技的數據庫工程師那裏得知,我們第一時間停止MySQL防止硬盤繼續寫入這個應急措施是錯誤的,即使分區完全沒有文件,mysql的進程繼續運行,只要保留這個現場,可以從內存中獲取更多的數據庫結構信息,對恢復數據非常有幫助。
三.事故後恢復工作
事故後恢復工作從數據來源分爲4條線索進行:
1.硬盤上數據的恢復(主線)
2.從memcache導出的數據恢復
3.從binlog裏恢復
4.從搜索引擎的快照裏恢復頁面
以下按時間詳細敘述:
下一階段:
四.所缺失的近兩月數據當前的恢復情況
至今,內容大多得到了99%左右的恢復。缺失部分並不是來自硬盤數據丟失,而是6月26日12點前id移位至大值前,半天創建的內容和原位置內容的衝突,我們還在盡力修補。
以下是當前主要內容的恢復情況:
恢複比例
五.致謝
特別感謝一下三個公司和個人在這7天的恢復工作中對我們的幫助。
杭州沃趣網絡科技有限公司(@沃趣科技)是來自原阿里巴巴DBA/SA團隊核心骨幹組建的創業公司,提供數據庫和系統相關的專業服務和產品,陳棟(@grassbell)、李春(@pickup112)對破損的數據庫文件進行了災難修復,提取出絕大部分數據表的內容。
周振興(@orczhou)是淘寶MySQL數據庫運維負責人,他對破損文件中部分帶二進制段的數據表進行了修復,提取到了相關內容。
北亞數據恢復中心是來自前信息產業部職鑑中心,專門從事數據恢復服務的技術公司。張宇,劉子龍對硬盤文件進行了完整的恢復,使我們得到了數據庫的全部數據。
http://www.xshell.net/database/1299.html
【博主評論】
在遷移前的準備階段:
1 本次遷移,實際上涉及到了mysql升級,主庫升級爲5.5,從庫版本低於主庫。沒有意識到這個問題,mysql升級後,必然出問題
2 對備份不夠重視
即使從庫作爲實時備份,仍然需要保證另外一種備份策略,保證數據尤其是核心數據存在“強有力”的副本
遷移過程中:
1 沒有一個非常清楚完整的checklist,難免會“丟三落四”,忘記操作某些步驟
2 操作不規範,沒有一個合理的規範或制度能保證重大操作的風險可控
處理事故階段:
1 操作不科學,比如,第一時間操作人員執行了停mysql服務,而科學的方法是不能停止mysql
2 多人溝通尤其是跨部門溝通,不順暢,導致效率低下
其實,這些也在一定程度上反映了平時工作中,技術不過硬,操作不規範,缺乏保障機制,對數據庫尤其是備份不重視等問題