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

下面把整個(gè)事故過(guò)程記錄下來(lái)，令關(guān)心本次技術(shù)事故的人們知曉。

一. 事故隱患

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

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

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

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

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

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

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

當(dāng)天的應(yīng)急工作至凌晨4點(diǎn)，服務(wù)器都恢復(fù)訪問(wèn)，但數(shù)據(jù)停留在4月23日。

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

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

三. 事故后恢復(fù)工作

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

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

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

3. 從binlog里恢復(fù)

4. 從搜索引擎的快照里恢復(fù)頁(yè)面

以下按時(shí)間詳細(xì)敘述：

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

下一階段：

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

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

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

以下是當(dāng)前主要內(nèi)容的恢復(fù)情況：

五. 致謝 

特別感謝一下三個(gè)公司和個(gè)人在這7天的恢復(fù)工作中對(duì)我們的幫助。

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

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

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