如何恢復Mysql資料庫的詳細介紹

由於在一臺測試機器上打算重新安裝Mysql資料庫，由於簡單粗暴的直接解除安裝了，沒有備份公司Discuz和Redmine使用的Mysql資料庫，過程可想的悲慘。

還好的是隻是解除安裝掉了Mysql的程式，所有的資料檔案還是存在的。

下面是在恢復資料庫的過程

1. Discuz資料庫

Discuz資料庫的恢復非常順利， 在安裝好新版本的Mysql後，直接將原來的資料庫檔案copy到新的資料目錄中，重新啟動mysql, 就能看到恢復的資料庫了

2. Redmine資料庫

本打算直接使用上面的經驗，也能看到所有的表，但是就是執行查詢的時候，總是報錯"表不存在".

後來查了一些資料，發現，原因應該是Discuz和Redmine使用的Mysql引擎不一樣導致的。

Discuz使用的是MyISAM, 而Redmine使用的是InnoDB.

解決的辦法是,

除了要copy資料目錄外，還要記得覆蓋ibdata1檔案。

以表”Table”為例: 如型別是MyISAM, 資料檔案則以”Table.frm””Table.MYD””Table.MYI””三個檔案儲存於”/data/$databasename/”目錄中. 如型別是InnoDB, 資料檔案則儲存在”$innodb_data_home_dir/″中的ibdata1檔案中(一般情況)，結構檔案存在於table_name.frm中. MySQL的資料庫檔案直接複製便可以使用，但是那是指“MyISAM”型別的表。 而使用MySQL-Front直接建立表，預設是“InnoDB”型別，這種型別的一個表在磁碟上只對應一個“*.frm”檔案，不像MyISAM那樣還“*.MYD,*.MYI”檔案。 MyISAM型別的表直接拷到另一個資料庫就可以直接使用，但是InnoDB型別的表卻不行。解決方法就是:

同時複製innodb資料庫表“*.frm”檔案和innodb資料“ibdata1”檔案到合適的位置。啟動MySQL的Windows服務 由於MySQL這樣資料混雜的形式, 往往很容易讓使用者在備份時忘記了備份InnoDB, 從而導致了上述錯誤.

意思就是說在資料庫引擎型別為InnoDB時，複製資料檔案的同時還需要複製ibdata1，於是把ibdata1也複製過去覆蓋，發現還是有點問題，於是停止mysql服務，將目錄下的ib_logfile*檔案全部刪除掉，重新啟動mysql服務，well done，可以了

高興啊，於是稍微總結了，希望以後遇到相同的問題，能夠快速解決。

1，在進行mysql資料庫備份的或遷移的時候，儘量備份完成所需要的資料；

2，如果直接複製原有資料庫檔案"*.frm"、"*.MYD"、"*.MYI"等檔案時候，如果原資料庫引擎是InnoDB,切記還需複製ibdata1檔案

3，備份資料庫的時候，最好是用相關的工具進行備份或是匯出sql檔案，以免浪費時間在資料庫恢復上

4，msyql版本或是備份工具的版本不同，也可能引起資料恢復有問題。

實踐證明以上問題是存在的，解決方案是可行的，哈哈，為了以後方便，寫了這篇部落格隨筆，希望大牛看到了不要鄙視，歡迎拍磚。

 1：MyISAM型別的資料檔案可以在不同作業系統中COPY，這點很重要，佈署的時候方便點。（只需要複製 資料庫名字資料夾下面的檔案，這樣資料庫就複製完了）

2:  InnoDB型別的 要注意多複製 ibdata1 , 最好不要是直接複製資料夾，而是應該用sql匯入匯出