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模式。僅在匯入整個表或表的一個片斷之後提交。