在6月26日凌晨12點左右，我們在做線上數(shù)據(jù)庫的備庫時，誤將線上數(shù)據(jù)庫分區(qū)上的所有文件刪除。丟失的數(shù)據(jù)時間段為4月23日至6月25日兩個月，在經(jīng)過7天的努力后，恢復了99%以上的數(shù)據(jù)。（具體見下面的統(tǒng)計）。

下面把整個事故過程記錄下來，令關心本次技術事故的人們知曉。

一. 事故隱患

現(xiàn)在回顧，事故隱患在4月23日之后就已經(jīng)存在。

我們線上數(shù)據(jù)庫使用的是MySQL，在4月23日之前，我們對線上數(shù)據(jù)庫主節(jié)點有三類備份。一是有一個獨立的數(shù)據(jù)庫從節(jié)點來備份，與線上服務器保持數(shù)據(jù)的實時同步，需要時可切換作線上使用。二是會定期把整個數(shù)據(jù)庫dump成sql文件來備份，一天保存一次，備份的來源是數(shù)據(jù)庫從節(jié)點。三是主節(jié)點開啟有binlog，默認是保存十天的日志，十天內有任何事故可以從日志里完整恢復全部數(shù)據(jù)。這三個備份分別存放在兩臺不同的物理機，三個不同的分區(qū)上，是當時想到的最安全的方式。

4月23日，我們把數(shù)據(jù)庫主節(jié)點遷移到一臺新的物理機上，并把版本升級到5.5。由于版本和配置的問題，原來的從節(jié)點并不能直接使用。而一天一次的備份來源是從節(jié)點（備份主節(jié)點會令網(wǎng)站和手機app有1小時左右的卡頓），這個備份方式也就停止了更新。只有最后一個binlog還在運行。數(shù)據(jù)庫遷移之后應用服務器存在一些性能問題需要投入時間，包括修復MySQL5.5版本和原代碼的兼容，以及把應用服務器從gunicorn換成uwsgi，之后又陸續(xù)有一些開發(fā)任務，以致重新啟用備份節(jié)點的工作一再拖延。

我們對數(shù)據(jù)庫遷移工作的管理存在失誤，是造成事故的根本原因。沒有完成數(shù)據(jù)庫備份節(jié)點，遷移工作就并沒有結束。我們技術團隊的所有人對這個事故都負有責任，這個隱患在兩個月里都可能被發(fā)現(xiàn)，每個人都有可能提出這個工作的高優(yōu)先級。也都可能提出相應的彌補工作來保證數(shù)據(jù)安全，比如在啟用從節(jié)點前延長二進制日志的保存時間等。是我們的工作失誤使數(shù)據(jù)庫成為系統(tǒng)最脆弱的環(huán)節(jié)，經(jīng)受不住偶然事故的沖擊。

二. 事故發(fā)生過程

6月26日凌晨12點左右，我們開始重新建立備份節(jié)點的工作，需要把原來的從節(jié)點刪除，重新安裝，所以先使用了rm -f方式刪除備份節(jié)點分區(qū)上的所有文件。

5分鐘后，發(fā)現(xiàn)剛才刪除的是數(shù)據(jù)庫主節(jié)點的分區(qū)，為防止硬盤繼續(xù)寫入，就馬上把mysql進程停止了。所有技術人員開始應急處理。一是把整個分區(qū)dd成鏡像，準備做將來硬盤恢復的備份。二是把memcache里的數(shù)據(jù)dump出來，以備可能的恢復。三是重新啟用原來的從數(shù)據(jù)庫，由于數(shù)據(jù)時間只到4月23日，需要調整近兩月表結構變更，讓最新的代碼可以跑起來。

當天的應急工作至凌晨4點，服務器都恢復訪問，但數(shù)據(jù)停留在4月23日。

在整個應急過程中，部分是緊張，部分是溝通上存在誤解，還是出現(xiàn)了失誤。當配置從數(shù)據(jù)庫的技術人員完成之后，重啟了服務器和memcache，恢復了正常訪問。但是做memcache導出工作的技術人員還沒有完成，所以最終能從memcache里得到的那部分數(shù)據(jù)只有一半左右。

事后從沃趣科技的數(shù)據(jù)庫工程師那里得知，我們第一時間停止MySQL防止硬盤繼續(xù)寫入這個應急措施是錯誤的，即使分區(qū)完全沒有文件，mysql的進程繼續(xù)運行，只要保留這個現(xiàn)場，可以從內存中獲取更多的數(shù)據(jù)庫結構信息，對恢復數(shù)據(jù)非常有幫助。

三. 事故后恢復工作

事故后恢復工作從數(shù)據(jù)來源分為4條線索進行：

1. 硬盤上數(shù)據(jù)的恢復（主線）

2. 從memcache導出的數(shù)據(jù)恢復

3. 從binlog里恢復

4. 從搜索引擎的快照里恢復頁面

以下按時間詳細敘述：

• 6月26日8點，我們去機房把服務器硬盤取出來，送到了一家硬盤數(shù)據(jù)恢復公司。到下午5點左右恢復出ibdata1文件，文件可能破損。
• 6月26日12點，為了預防新插入的內容和原內容的沖突，我們把所有表的id都加到一個大值，半天的內容隨后做特殊處理。
• 6月26日23點，導入完了所有memcache里的數(shù)據(jù)。
• 6月27日上午，從硬盤里又恢復出部分.ibd文件，也包含部分數(shù)據(jù)信息。已確定包含數(shù)據(jù)的ibdata1和.ibd文件有破損，無法直接使用，只能嘗試從破損文件中提取部分有效信息。
• 6月27日下午，聯(lián)系上杭州沃趣網(wǎng)絡科技有限公司的陳棟、李春，開始對數(shù)據(jù)的提取工作。至凌晨1點，提取出.ibd文件的數(shù)據(jù)，恢復部分表。
• 6月28日全天，沃趣科技開始對ibdata1文件的提取，至29日凌晨1點，他們已經(jīng)提出大部分數(shù)據(jù)。
• 6月28日下午，得到阿里巴巴集團的周振興的友情支持，他開始幫忙做ibdata1文件的提取工作，至凌晨4點，他完成部分帶二進制段的數(shù)據(jù)表的修復，提取到了相關內容。
• 6月28日下午，我們聯(lián)系上北亞數(shù)據(jù)恢復中心，開始再次嘗試對硬盤文件的恢復。
• 6月28日晚，我們把所有從binlog來的數(shù)據(jù)導入完，完整恢復了最后10天的數(shù)據(jù)。
• 6月29日中午，從沃趣科技得到的優(yōu)先級較高的數(shù)據(jù)表已經(jīng)恢復完成，開始恢復次優(yōu)先級的數(shù)據(jù)。
• 6月30日中午，提取完所有能從6月27日獲取的破損數(shù)據(jù)庫文件里的所有內容。至此這一階段提取到缺失總數(shù)據(jù)量的近70%。
• 6月30日下午，開始從搜索引擎快照里抓取部分菜譜重要頁面，修補缺失的內容。并聯(lián)系上某搜索引擎的快照部門，希望獲取我們網(wǎng)站的全部頁面快照。
• 7月1日上午，北亞數(shù)據(jù)恢復中心取得很大的進展，提取到幾乎是完整的ibdata1文件，至下午6點，提取到除了收藏和贊的所有數(shù)據(jù)表，我們開始把數(shù)據(jù)導入，至凌晨4點，恢復完得到的所有數(shù)據(jù)。
• 7月2日整天，由于導入的舊數(shù)據(jù)和新注冊的用戶存在部分數(shù)據(jù)不一致，我們盡力配合用戶恢復。
• 7月2日下午4點，北亞提取到ibdata1剩下的文件碎片，得到了完整的ibdata1文件，mysql無報錯啟動，我們得到了6月26日凌晨事故前的完整數(shù)據(jù)庫。至凌晨2點，我們提取出剩下的收藏和贊，恢復到數(shù)據(jù)庫里。至此損失的數(shù)據(jù)內容已經(jīng)恢復到99%。

下一階段：

• 在丟失兩個月數(shù)據(jù)的這一周時間里，用戶新產(chǎn)生的數(shù)據(jù)和恢復的舊數(shù)據(jù)會有少量不兼容的情況，我們會全力幫助用戶找回自己的全部數(shù)據(jù)，出現(xiàn)的錯誤敬請用戶包涵，幫助我們走過這一過渡階段。
• 除了原先的三種備份方式外，我們會繼續(xù)落實和第三方的云存儲方案的合作，把數(shù)據(jù)備份到我們的服務器之外的地方。

四. 所缺失的近兩月數(shù)據(jù)當前的恢復情況

至今，內容大多得到了99%左右的恢復。缺失部分并不是來自硬盤數(shù)據(jù)丟失，而是6月26日12點前id移位至大值前，半天創(chuàng)建的內容和原位置內容的沖突，我們還在盡力修補。

以下是當前主要內容的恢復情況：

五. 致謝 

特別感謝一下三個公司和個人在這7天的恢復工作中對我們的幫助。

杭州沃趣網(wǎng)絡科技有限公司(@沃趣科技)是來自原阿里巴巴DBA/SA團隊核心骨干組建的創(chuàng)業(yè)公司，提供數(shù)據(jù)庫和系統(tǒng)相關的專業(yè)服務和產(chǎn)品，陳棟（@grassbell）、李春（@pickup112）對破損的數(shù)據(jù)庫文件進行了災難修復，提取出絕大部分數(shù)據(jù)表的內容。

周振興（@orczhou）是淘寶MySQL數(shù)據(jù)庫運維負責人，他對破損文件中部分帶二進制段的數(shù)據(jù)表進行了修復，提取到了相關內容。

北亞數(shù)據(jù)恢復中心是來自前信息產(chǎn)業(yè)部職鑒中心，專門從事數(shù)據(jù)恢復服務的技術公司。張宇，劉子龍對硬盤文件進行了完整的恢復，使我們得到了數(shù)據(jù)庫的全部數(shù)據(jù)。