一次修改數據庫物理文件形成Mysql宕機的恢復記錄

事件起始

某夜，我正在牀上冥想準備入睡，突然同事向我求救：消息內容以下：

Oh My Gold 改了些配置，啥都沒了!都沒了!沒了!了!

我仔細詢問，原來是她由於某些緣由將某庫的物理文件夾更名後，發現數據庫找不到了。因而又將名稱改回來。結果仍然找不到。這讓她以爲數據可能被損壞了，因而趕緊來找我修復。

修復過程

咱們數據庫用的版本是 MySQL5.7 ,放置在Linux服務器上，在my.cnf 配置了數據庫物理文件的存放地址。存放於 data 文件夾下。

表的存儲引擎所有使用 InnoDB，data 目錄的文件依次以下

• 用數據庫名命名的文件夾，文件夾內存放的 .ibd , .frm 文件依次是數據庫表數據文件和表結構文件
• ibdata1 (存放InnoDB表元數據、undo logs、the change buffer, and the doublewrite buffer) 文件
• ib_logfile0 ，ib_logfile1 事務日誌

這個時候我首先想到的是我本機用Navicat備份過一個文件，馬上打開Navicat嘗試還原備份，然而日誌全是 Err錯誤，顯示錶存在，可是咱們是看不到的。這時候我就打算刪除該庫，直接使用備份恢復，然而數據庫刪除仍然報錯。我只得去備份了一下物理文件而後刪除。刪除後再使用Navicat還原

通過一番操做，數據庫文件是回來了。可是我電腦上的備份文件他不是實時的，雖然恢復了數據庫，但仍然丟失了部分數據，我心有不甘。因而我想了一個「妙計」： 我把剛纔備份的物理文件裏面的 .frm .ibd 文件替換到新建立的物理文件夾中。這樣狸貓換太子以後，我豈不是就擁有了最完整的數據？

說幹就幹，一通 cp -rf 事後，成功替換掉原來的文件。打開Navicat鏈接沒有問題，內心竊喜。就在這時，陸續有同事反應數據庫連不上了，個人天吶。什麼鬼？我打開MoBa查看linux 進程，發現Mysql 服務已經宕掉了。我嘗試重啓，報出以下錯誤：

查看Mysql 錯誤日誌：

This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

通過上網查詢，說是能夠經過在 my.cnf 添加以下的配置來強制啓動數據庫官方文檔對於該配置的解釋 ，同類問題的回答

[mysqld]
innodb_force_recovery = 1

• 1 （SRV_FORCE_IGNORE_CORRUPT）

  使服務器即便檢測到損壞的頁也能夠運行 。嘗試跳過損壞的索引記錄和頁，這有助於轉儲表。

• 2 （SRV_FORCE_NO_BACKGROUND）

  阻止主線程和任何清除線程運行。若是在清除操做期間發生崩潰，則此恢復值可防止崩潰。

• 3 （SRV_FORCE_NO_TRX_UNDO）

  崩潰恢復後 不運行事務回滾。

• 4 （SRV_FORCE_NO_IBUF_MERGE）

  防止插入緩衝區合併操做。若是它們會致使崩潰，請不要這樣作。不計算表 統計信息。此值可能會永久損壞數據文件。使用此值後，準備刪除並從新建立全部二級索引。設置 InnoDB爲只讀。

• 5 （SRV_FORCE_NO_UNDO_LOG_SCAN）

  啓動數據庫時 不查看撤消日誌： InnoDB甚至將未完成的事務也視爲已提交。此值可能會永久損壞數據文件。設置InnoDB爲只讀。

• 6 （SRV_FORCE_NO_LOG_REDO）

  不進行與恢復有關的重作日誌前回滾。此值可能會永久損壞數據文件。使數據庫頁面處於過期狀態，這又可能致使B樹和其餘數據庫結構遭受更多破壞。設置 InnoDB爲只讀。

官方文檔特別說明：當級別 >= 4 時，可能會對數據庫文件形成不可挽回的破壞。我嘗試從1 開始逐步修改該值啓動。直到 6 才正常啓動。啓動後，只能執行查詢語句，增刪改都不行。因而我將數據庫文件所有備份後。關閉數據庫，刪除原來的 數據庫物理文件、ibdata1 文件、ib_logfile0 文件。以後將 innodb_force_recovery 值還原爲默認值0。從新恢復了數據庫文件。解除了這次危機。

啓發

1. 定時備份數據庫！即便是測試庫。測試庫能夠調的時間間隔長一點
2. 在不懂的狀況下不要自做聰明亂動物理文件！