mysql/mariadb的數據恢復。沒有libdata1，只有frm和idb文件的innodb的數據恢復

因爲服務器系統緣由，在更新完成系統後發現新版的linux並不兼容老的硬件，致使系統崩潰，而我又未備份系統（惟獨此次），致使系統沒法正常啓動，至關於啓動不了，而後就是數據庫和服務全炸了。好在進入單用戶模式下將數據庫拷貝出來了。拷貝的數據庫直接是所有的包，裏面未包含libdata文件，只有數據庫文件的frm以及idb，因爲場景緣由採用了innodb引擎的緣故。數據直接放在一個正常的機器下沒法使用。應該是已經損壞。好在進行了以前的數據備份，因此不用在作frm的表導出操做。至於不會的直接參照下面

利用MySql InnoDb還原工具還原innodb數據庫，只包含了.frm及.ibd文件，方法以及工具http://www.zcgonvh.com/post/mysql_innodb_restore.html

具體的方案做者已經說明，這裏不在進行說明。我主要將下數據恢復的過程。

準備工做：

• windows（或linux）
• navicat for mysql
• frm文件以及idb文件

 安裝mysql數據庫，建立數據庫數據編碼必須一致

還原步驟：

1.    恢復原始的備份數據，主要是要表結構。

2.    原始數據恢復完成後將表空間卸載（innodb）。操做語句 alter table `要恢復的表名稱` discard tablespace

3.    刪除當前數據下面剛纔卸載表空間的表文件（idb文件）

4.     將要恢復的文件複製到剛纔刪除文件的位置。

5.    執行表空間加載 alter table `要恢復的表名稱` import tablespace; 、

此時就在打開表就能夠看到恢復的數據了。

恢復過程當中可能會有如下的問題

1.數據恢復出現錯誤 mysql err 1808 （ERROR 1808），出現此類錯誤大部分狀況下是因爲當前恢復的數據版本與要恢復的數據以前的數據庫運行版本不一致致使的，如mysql5.5 到 mysql 5.7之間恢復，或mariadb10.0與mariadb 10.3等。解決方法 第一種：更換數據庫版本與損壞數據庫版本一致，進行恢復操做便可。第二種：從新導入表結構，在建立表的時候加上 row_format=compact 這句話便可。而後再使用恢復方法進行回覆便可。

2.表不存在The storage engine for the table doesn't support repair沒法修復，或1932 - Table 'XXX' doesn't exist in engine等錯誤提示不存在。解決方法：檢查表的idb的權限是否知足，在linux中必須是可讀寫權限，不然沒法發現和修復數據。

3.恢復出的innodb數據亂碼。這個是最容易產生的狀況，我在恢復數據的時候發現數據中的時間所有是 「0000-00-00 00:00:22」，還有一些中文產生了亂碼。找了大量的資料沒有，只有本身來摸索研究。

    解決辦法：

        第一種狀況，數據庫版本不匹配，從新安裝數據庫版本便可，

        第二種狀況，windows的環境下或者linnux的出現的，檢查下是不是操做系統環境有問題，建議在恢復的時候安裝在同等的操做環境下。

        第三種狀況，數據庫的編碼錯誤，建立數據庫表的時候用的是gbk而恢復的數據是utf-8等這樣相似的狀況都屬於編碼錯誤致使。

4.    本人也有看別人說採用innodb_force_recovery 等操做方案，通過個人測試，本次恢復無效，恢復出來是大量的錯誤數據，大概有70%的正常數據，其餘的所有是錯誤的。不建議採用。引用下：https://my.oschina.net/ion/blog/526649

注意如下幾點就放棄恢復了，或者說本方法不適合恢復工做。

1.    數據庫爲共享數據庫，能夠查下共享數據庫的概念。此時的恢復必須有lbdata才能夠恢復。

2.    idb文件損壞，此時文件是沒法被使用的，建議在備份後設置爲只讀模式進行恢復工做。

3.    表中含有大量的索引和外鍵約束，此時恢復的數據只能夠看不能將恢復的表直接用於生產環境，修復、驗證後才能夠進行生產環境的替換。

4.     其餘未知問題，（我沒發現，還請自行留意）

=========================================================================================

寫在最後，別沒事就升級系統或者斷電，先備份數據纔是關鍵。