十年難得一遇！從數(shù)據(jù)誤刪到全量恢復(fù)的驚險記錄

來自：DBAplus社群

作者介紹

線上的數(shù)據(jù)庫服務(wù)我們有完善的備份策略和恢復(fù)預(yù)案，數(shù)據(jù)即使被誤刪除了也是能夠恢復(fù)的，誤刪除的數(shù)據(jù)量恢復(fù)只是時間問題。但各位同學自己部署的測試環(huán)境或者是在自己電腦中的開發(fā)環(huán)境的數(shù)據(jù)庫就沒有同級別的資源保障了。如果恰好你又把一些不能丟失的數(shù)據(jù)放到了這種環(huán)境中，那么建議要做定期備份，有備才能無患。

今天給大家分享的案例便是這種在線下自搭建環(huán)境的一次數(shù)據(jù)誤刪除事件。數(shù)據(jù)不幸被刪除和萬幸能被全量恢復(fù)可謂十年一遇。

測試環(huán)境中的一臺服務(wù)器準備做遷移替換，小 A 同學接到了這個光（危）榮（險）的任務(wù)。小 A 選擇了直接 rm -rf /mysql 刪除這臺機器上掛載的數(shù)據(jù)分區(qū)來清理磁盤空間。

不到兩分鐘，還在挑燈夜戰(zhàn)的某位同學就發(fā)現(xiàn)一個常用的測試環(huán)境無法正常使用了。這時候的小 A 定是心如止（死）水（灰），還是找 DBA 幫忙看看吧。

值班 DBA 小 D 被電話叫起緊急支援，但小 D 登錄到服務(wù)器上一看也淡（傻）定（眼）了，數(shù)據(jù)、日志、軟件環(huán)境統(tǒng)統(tǒng)都被刪除了，唯一的一次備份是一年前升級測試環(huán)境數(shù)據(jù)庫時做的備份。給 DBA 老 A 打電話吧，問問他的建議。

一旦發(fā)生了誤刪數(shù)據(jù)先不要慌，停止所有操作，第一時間尋求幫助。即使您是老司機，這時候也要找一位同學幫忙一起觀察后續(xù)的操作，避免手抖出現(xiàn)再次誤操作。

另外要強調(diào)的是，在出現(xiàn)數(shù)據(jù)誤刪除的服務(wù)器上同時只能有一個人操作，其他人應(yīng)通過桌面共享軟件或站在操作人身后觀察，避免多人交叉操作出現(xiàn)二次故障。

老 A 在得知數(shù)據(jù)、日志和軟件環(huán)境都被刪除后，先使用了 ps 命令查看 mysqld 進程是否還存活。

進程還在，這就有戲了，不幸中的萬幸。抓緊到 /proc/${pid}/fd 目錄看看有沒有還未關(guān)閉的表可以搶救。

真是太幸運了，這個測試環(huán)境里面的表比較少，所有表的數(shù)據(jù)文件還都是打開狀態(tài)。數(shù)據(jù)被找回的概率就很大了。接下來就是如何把這些顯示為 deleted 的文件從文件系統(tǒng)中找回了。

在介紹如何找回被刪除的文件前，先來介紹一個運維經(jīng)常會遇到的刪除了文件，但磁盤空間不釋放的問題。下圖是一個模擬的例子，當 test.txt 文件被 tail -f 命令使用時，rm test.txt 并不會釋放空間，當將 tail -f 命令 ctrl+c 中止后，磁盤空間才釋放。

一個文件在文件系統(tǒng)中的存放分為兩個部分：數(shù)據(jù)部分和指針部分，指針位于文件系統(tǒng)的 meta-data 中，數(shù)據(jù)被刪除后，這個指針就從 meta-data 中清除了，而數(shù)據(jù)部分存儲在磁盤中，數(shù)據(jù)對應(yīng)的指針從 meta-data 中清除后，文件數(shù)據(jù)部分占用的空間就可以被覆蓋并寫入新的內(nèi)容，之所以出現(xiàn)刪除 test.txt 文件后，空間還沒釋放，就是因為 tail -f 進程還在一直打開這個文件句柄，文件對應(yīng)的指針部分由于進程鎖定，并未從 meta-data 中清除。由于指針并未被刪除，那么系統(tǒng)內(nèi)核就認為文件并未被刪除，因此通過 df 命令查詢空間并未釋放。

有了之前遇到的類似經(jīng)驗我們知道，MySQL 被刪除的數(shù)據(jù)由于句柄還在打開狀態(tài)，因此還未完成刪除，是可以被找回的，已經(jīng)關(guān)閉的表就無法找回了。找回的方法也比較簡單，直接 cat 對應(yīng)的文件句柄，再通過管道（pipe）或輸出重定向的方式即可找回原來的數(shù)據(jù)文件了。但要注意的是為了保證原來的磁盤不要再被寫入新的數(shù)據(jù)，不要在原分區(qū)下做磁盤寫操作。這次的環(huán)境是部署在云服務(wù)器上的，再掛載一塊新的云盤到這臺服務(wù)器上就能把數(shù)據(jù)文件找回了，找回方式如下圖所示：

如果讀者使用的是自己的筆記本，可以插一塊 U 盤或移動硬盤，將數(shù)據(jù)拷貝到 U 盤或移動硬盤；如果使用的是物理機可以考慮使用管道給 netcat 命令把數(shù)據(jù)文件傳輸?shù)搅硗庖慌_服務(wù)器。如下圖所示：

表比較多的話建議寫個腳本進行批量修復(fù)，注意提前分好目錄結(jié)構(gòu)，把對應(yīng)句柄的文件直接恢復(fù)到指定的目錄，便于后續(xù)處理。數(shù)據(jù)文件找回來啦！?。?/span>

數(shù)據(jù)文件已經(jīng)找回了，已經(jīng)算是完成了一半，至少業(yè)務(wù)的數(shù)據(jù)都在這些文件里面，但獨立的 ibd 文件是無法被 MySQL 識別的，需要配合表結(jié)構(gòu)定義文件（MySQL 5.7 之前為 frm 文件）才可使用。老 A 咨詢了業(yè)務(wù)同學，他們使用的是開源的服務(wù)，可以在其他環(huán)境上再部署一套，這樣就順利的拿到了這個服務(wù)的建表語句。

MySQL 5.6 以上版本支持通過 ALTER TABLE xxx DISCARD TABLESPACE 和 ALTER TABLE xxx IMPORT TABLESPACE 的方式來刪除和導入表空間文件（ibd 數(shù)據(jù)文件）。而我們這次的測試環(huán)境剛好是 5.7 的版本，支持這種語法，真是太幸運了。抓緊找個別的臨時環(huán)境來建表導入數(shù)據(jù)就好了。操作方式如下：

筆者在操作的時候使用的賬號不是 MySQL 賬號，導致第 4 步在引入表空間的時候提示表空間不存在，修改文件屬主再重新導入就可以了。提醒大家還是要沉著，不要忙中出錯。

完成了上一步千萬不要開心太早，由于原來的表空間是未正常關(guān)閉的，這種方式恢復(fù)的表不可直接使用，數(shù)據(jù)有無損壞還需要進一步驗證。這里老 A 建議把數(shù)據(jù)使用 mysqldump 出來，然后再恢復(fù)到準備遷移的新環(huán)境中。精力所限 MySQL 數(shù)據(jù)邏輯備份和恢復(fù)的方案這里就不再講解了，讀者可以自行搜索學習。

備份出來的數(shù)據(jù)表被導入到新環(huán)境后，老 A 請開發(fā)同學驗證了里面的數(shù)據(jù)，故障前最新的數(shù)據(jù)都還在，服務(wù)修改配置重新啟動功能正常，這時業(yè)務(wù)終于長出一口氣。

老話說“有備無患”，線上數(shù)據(jù)庫服務(wù)我們有每天的定時全量備份 ，還有基于 binlog 的實時增量備份。對于自已部署的環(huán)境也要加強備份意識。筆記本上的代碼要及時提交 git，產(chǎn)品文檔要及時上傳公司的云盤持久存儲。線上數(shù)據(jù)修改要提前備份修改前的內(nèi)容，刪除數(shù)據(jù)建議先標記刪除再物理刪除。