MYSQL中INNODB存儲引擎數據庫恢復方法

INNODB存儲引擎數據庫恢復方法與另一種類型的數據庫恢復是有區別的，下面本文章就為大家介紹MYSQL中INNODB存儲引擎數據庫恢復方法，希望文章能給各位帶來幫助哦。

MySQL的數據庫文件直接復制便可以使用，但是那是指“MyISAM”類型的表。
而使用MySQL-Front直接創建表，默認是“InnoDB”類型，這種類型的一個表在磁盤上只對應一個“*.frm”文件，不像MyISAM那樣還“*.MYD,*.MYI”文件。
MyISAM類型的表直接拷到另一個數據庫就可以直接使用，但是InnoDB類型的表
卻不行。解決方法就是:

同時拷貝innodb數據庫表“*.frm”文件和innodb數據“ibdata1”文件到合適的位置。啟動MySQL的Windows服務，如果不能成功的話，查看data文件夾中有個“*.err”錯誤日志文件，其中會對啟動失敗的原因有所描述的。比如我碰到過兩種錯誤原因。
一種是類似這樣的錯誤信息：

INIFile code

InnoDB: Error: log file .ib_logfile0 is of different size 0 10485760 bytes InnoDB: than specified in the .cnf file 0 25165824 bytes!

這是因為在mysql配置文件中配置的日志文件大小與實際的不相符。
解決方法是直接刪掉舊的“ib_logfile0”等日志文件，重啟MySQL後會自動生成新的日志文件的。
另一中則是這樣的錯誤信息

INIFile code

InnoDB: Operating system error number 5 in a file operation. InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. It may also be you have created a subdirectory InnoDB: of the same name as a data file. InnoDB: File name .ibdata1 InnoDB: File operation call: ‘open’. InnoDB: Cannot continue operation.

經檢查原來是“ibdata1”文件在復制的過程中不知怎的被加上只讀屬性了。
解決方法是去掉“ibdata1”文件的只讀屬性便可。

15.2.8.1. 強制恢復

如果數據庫頁被破壞，你可能想要用SELECT INTO OUTFILE從從數據庫轉儲你的表，通常以這種方法獲取的大多數數據是完好的。即使這樣，損壞可能導致SELECT * FROM tbl_name或者InnoDB後台操作崩潰或斷言，或者甚至使得InnoDB前滾恢復崩潰。 盡管如此，你可以用它來強制InnoDB存儲引擎啟動同時阻止後台操作運行，以便你能轉儲你的表。例如：你可以在重啟服務器之前，在選項文件的[mysqld]節添加如下的行：

[mysqld]

innodb_force_recovery = 4

innodb_force_recovery被允許的非零值如下。一個更大的數字包含所有更小數字的預防措施。如果你能夠用一個多數是4的選項值來轉儲你的表，那麼你是比較安全的，只有一些在損壞的單獨頁面上的數據會丟失。一個為6的值更誇張，因為數據庫頁被留在一個陳舊的狀態，這個狀態反過來可以引發對 B樹和其它數據庫結構的更多破壞。

· 1 (SRV_FORCE_IGNORE_CORRUPT)

即使服務器檢測到一個損壞的頁，也讓服務器運行著；試著讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助於轉儲表。

· 2 (SRV_FORCE_NO_BACKGROUND)

阻止主線程運行，如果崩潰可能在淨化操作過程中發生，這將阻止它。

· 3 (SRV_FORCE_NO_TRX_UNDO)

恢復後不運行事務回滾。

· 4 (SRV_FORCE_NO_IBUF_MERGE)

也阻止插入緩沖合並操作。如果你可能會導致一個崩潰。最好不要做這些操作，不要計算表統計表。

· 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

啟動數據庫之時不查看未完成日志：InnoDB把未完成的事務視為已提交的。

· 6 (SRV_FORCE_NO_LOG_REDO)

不要在恢復連接中做日志前滾。

數據庫不能另外地帶著這些選項中被允許的選項來使用。作為一個安全措施，當innodb_force_recovery被設置為大於0的值時，InnoDB阻止用戶執行INSERT, UPDATE或DELETE操作.

即使強制恢復被使用，你也可以DROP或CREATE表。如果你知道一個給定的表正在導致回滾崩潰，你可以移除它。你也可以用這個來停止由失敗的大宗導入或失敗的ALTER TABLE導致的失控回滾。你可以殺掉mysqld進程，然後設置innodb_force_recovery為3，使得數據庫被掛起而不需要回滾，然後捨棄導致失控回滾的表。
15.2.8.2. 檢查點

InnoDB實現一種被認識為“模糊”檢查點設置的檢查點機制。InnoDB以小批量從緩沖池刷新已修改的數據庫頁。沒必要以單個批次刷新緩沖池，單批次刷新實際操作中可能會在檢查點設置進程中停止用戶SQL語句的處理。

在崩潰恢復中，InnoDB找尋被寫進日志的檢查點標簽。它知道所有在該標簽之前對數據庫的修改被呈現在數據庫的磁盤映像中。然後InnoDB從檢查點往前掃描日志文件，對數據庫應用已寫入日志的修改。

InnoDB以循環方式寫日志文件。所有使得緩沖池裡的數據庫頁與磁盤上的映像不同的已提交修改必須出現在日志文件中，以備萬一InnoDB需要做一個恢復。這意味著，當InnoDB開始重新使用一個日志文件，它需要確認在磁盤上的數據庫頁映像包含已寫進InnoDB准備重新使用的日志文件裡的修改。換句話說，InnoDB必須創建一個檢查點，這經常涉及已修改數據庫頁到磁盤的刷新。

前面的敘述解釋了為什麼使你的日志文件非常大會在設置檢查點中節約磁盤I/O。設置日志文件總的大小和緩沖池一樣大或者甚至比緩沖池大通常是有意義的。大日志文件的缺點是崩潰恢復要花更長的時間，因為有更多寫入日志的信息要應用到數據庫上。
15.2.9. 把一個InnoDB數據庫移到另一台機器

在Windows上， InnoDB 總是在內部以小寫名字的方式存儲數據庫和表。要從Unix把二進制格式的數據庫移到Windows，或者從Windows移到Unix，你應該讓所有表和數據庫的名字小寫。要實現這個，一個方便的方式是在創建任何數據庫和表之前，在你的my.cnf或my.ini文件的[mysqld]節內添加如下行：

[mysqld]

lower_case_table_names=1

類似於MyISAM數據文件，InnoDB數據和日志文件在所有有相同浮點數格式的平台上是二進制兼容的。你可以拷貝所有列在15.2.8節，“InnoDB數據庫的備份和恢復”裡的相關文件來簡單地移動一個InnoDB數據庫。如果浮點格式不同，但你沒有在表中使用FLOAT或DOUBLE數據類型，則過程是一樣：簡單地拷貝相關文件。如果格式不容，且你的表包含浮點數據，你必須使用mysqldump在一台機器轉儲你的表，然後在另一台機器導入轉儲文件。

假設表空間有足夠的空間供導入事務產生的大型回滾片斷使用，則提高性能的一個方法是在導入數據時關掉autocommit模式。僅在導入整個表或表的一個片斷之後提交。