由于在一臺測試機器上打算重新安裝Mysql數(shù)據(jù)庫，由于簡單粗暴的直接卸載了，沒有備份公司Discuz和Redmine使用的Mysql數(shù)據(jù)庫，過程可想的悲慘。

還好的是只是卸載掉了Mysql的程序，所有的數(shù)據(jù)文件還是存在的。

下面是在恢復數(shù)據(jù)庫的過程

1. Discuz數(shù)據(jù)庫

Discuz數(shù)據(jù)庫的恢復非常順利， 在安裝好新版本的Mysql后，直接將原來的數(shù)據(jù)庫文件copy到新的數(shù)據(jù)目錄中，重新啟動mysql, 就能看到恢復的數(shù)據(jù)庫了

2. Redmine數(shù)據(jù)庫

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

后來查了一些資料，發(fā)現(xiàn)，原因應該是Discuz和Redmine使用的Mysql引擎不一樣導致的。

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

解決的辦法是,

除了要copy數(shù)據(jù)目錄外，還要記得覆蓋ibdata1文件。

以表”Table”為例: 如類型是MyISAM, 數(shù)據(jù)文件則以”Table.frm””Table.MYD””Table.MYI””三個文件存儲于”/data/$databasename/”目錄中. 如類型是InnoDB, 數(shù)據(jù)文件則存儲在”$innodb_data_home_dir/″中的ibdata1文件中(一般情況)，結(jié)構(gòu)文件存在于table_name.frm中. MySQL的數(shù)據(jù)庫文件直接復制便可以使用，但是那是指“MyISAM”類型的表。 而使用MySQL-Front直接創(chuàng)建表，默認是“InnoDB”類型，這種類型的一個表在磁盤上只對應一個“*.frm”文件，不像MyISAM那樣還“*.MYD,*.MYI”文件。 MyISAM類型的表直接拷到另一個數(shù)據(jù)庫就可以直接使用，但是InnoDB類型的表卻不行。解決方法就是:

同時拷貝innodb數(shù)據(jù)庫表“*.frm”文件和innodb數(shù)據(jù)“ibdata1”文件到合適的位置。啟動MySQL的Windows服務(wù) 由于MySQL這樣數(shù)據(jù)混雜的形式, 往往很容易讓使用者在備份時忘記了備份InnoDB, 從而導致了上述錯誤.

意思就是說在數(shù)據(jù)庫引擎類型為InnoDB時，拷貝數(shù)據(jù)文件的同時還需要拷貝ibdata1，于是把ibdata1也拷貝過去覆蓋，發(fā)現(xiàn)還是有點問題，于是停止mysql服務(wù)，將目錄下的ib_logfile*文件全部刪除掉，重新啟動mysql服務(wù)，well done，可以了

高興啊，于是稍微總結(jié)了，希望以后遇到相同的問題，能夠快速解決。

1，在進行mysql數(shù)據(jù)庫備份的或遷移的時候，盡量備份完成所需要的數(shù)據(jù)；

2，如果直接拷貝原有數(shù)據(jù)庫文件"*.frm"、"*.MYD"、"*.MYI"等文件時候，如果原數(shù)據(jù)庫引擎是InnoDB,切記還需拷貝ibdata1文件

3，備份數(shù)據(jù)庫的時候，最好是用相關(guān)的工具進行備份或是導出sql文件，以免浪費時間在數(shù)據(jù)庫恢復上

4，msyql版本或是備份工具的版本不同，也可能引起數(shù)據(jù)恢復有問題。

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

 1：MyISAM類型的數(shù)據(jù)文件可以在不同操作系統(tǒng)中COPY，這點很重要，布署的時候方便點。（只需要拷貝 數(shù)據(jù)庫名字文件夾下面的文件，這樣數(shù)據(jù)庫就拷貝完了）

2:  InnoDB類型的 要注意多拷貝 ibdata1 , 最好不要是直接復制文件夾，而是應該用sql導入導出