若何恢復Mysql數據庫的具體引見。本站提示廣大學習愛好者：（若何恢復Mysql數據庫的具體引見）文章只能為提供參考，不一定能成為您想要的結果。以下是若何恢復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導入導出
