[[322751]]

作者介紹

貝殼找房DBA團隊，負責支撐起貝殼找房平臺的數據庫運維及數據庫產品的開發工作，努力提供高效、穩定、安全的數據庫服務。

引言

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

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

事件背景

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

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

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

[[322752]]

恢復經歷

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

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

1、找回數據文件

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

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

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

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

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

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

如果讀者使用的是自己的筆記本，可以插一塊 U 盤或移動硬盤，將數據拷貝到 U 盤或移動硬盤;如果使用的是物理機可以考慮使用管道給 netcat 命令把數據文件傳輸到另外一臺服務器。如下圖所示：

表比較多的話建議寫個腳本進行批量修復，注意提前分好目錄結構，把對應句柄的文件直接恢復到指定的目錄，便于后續處理。數據文件找回來啦!!!

[[322755]]

2、恢復數據文件

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

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

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

3、重建環境

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

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

總結

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

本文轉載自微信公眾號「DBAplus社群」，可以通過以下二維碼關注。轉載本文請聯系DBAplus社群公眾號。