InnoDB 中文參考手冊 --- 6 備份和恢復 InnoDB 資料庫 (轉)

InnoDB 中文參考手冊 --- 6 備份和恢復 InnoDB 資料庫 (轉)[@more@] words" content="My,InnoDB,4.1.0,Shuixin13, 4.1.0,中文,中文參考手冊,犬犬(心帆)"> CSS rel=STYLESHEET>

和恢復 InnoDB

的資料庫管理就是使用正規的資料備份。

InnoDB Hot Backup 是一個線上備份工具，你可以在 InnoDB 資料庫執行時使用它來實現線上備份。InnoDB Hot Backup 不需要你關閉你的也不需要加任何鎖或影響其它普通的資料操作。InnoDB Hot Backup 是一個非免費的附加工具，它的費用為每 MySQL 伺服器每年 400 歐元。瀏覽網頁 可獲得更多的資訊以及螢幕截圖。

如果你可以關閉你的 MySQL 服務，那麼可以透過下面幾個步驟進行資料庫的“二進位制”備份：

• 關閉 MySQL 資料庫服務，並確定在關閉時沒有發生任何錯誤
• 將你的所有資料複製到一個安全的地方
• 將所有的 InnoDB 日誌檔案複製到一個安全的地方
• 將 my.cnf 檔案複製到一個安全的地方
• 將所有的 InnoDB 表 .frm 檔案複製到一個安全的地方

在需要高的資料庫服務站點上，可以透過 MySQL 的複製特性來保持資料庫的一個副本，MySQL 的複製特性同樣適用於 InnoDB 表型別。

除了上面描述的二進位制備份方式之外，最好定期地使用 mysqldump 轉儲資料表。原因是二進位制檔案可能會在你未注意時而被破壞，而錶轉儲(dump)檔案是以文字檔案方式儲存的，它與二進位制檔案相比更簡單、有更好的的可讀性。因為轉儲檔案更簡單所以更容易發現表損壞， 重要資料損環的可能性很小。

一個好的主意就是在對資料庫做二進位制備份的同時也做一個轉儲(dump)備份。為了得到一致的資料快照，必須關閉所有客戶端的連線。然後就可以進行二進位制備份，這樣你就有了資料一致的兩種格式的備份。

如了實現透過上面所述的二進位制備份方法將 InnoDB 資料庫恢復到當前狀態，必須開啟 MySQL 的二進位制日誌(binlogging)開關。這樣你就可以二進位制日誌 與備份資料配合實現分時間點的恢復：

mysqlbinlog yourhostname-bin.123 | mysql

　

為了恢復一個崩潰了的 MySQL 服務程式，你所能做的唯一一件事就是重新啟動。InnoDB 將自動地檢查日誌並完成資料庫的前滾(roll-forward)到當前狀態。同時，InnoDB 將自動回滾崩潰前未提交的事務。在恢復過程中，mysqld 將顯示如下所示的提示：

heikki@donna:~/mysql-3.23.48/sql> mysqld 020204 23:08:31 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 177573790 InnoDB: Doing recovery: scanned up to log sequence number 0 177638912 InnoDB: Doing recovery: scanned up to log sequence number 0 177704448 InnoDB: Doing recovery: scanned up to log sequence number 0 177769984 InnoDB: Doing recovery: scanned up to log sequence number 0 177835520 InnoDB: Doing recovery: scanned up to log sequence number 0 177901056 InnoDB: Doing recovery: scanned up to log sequence number 0 177966592 InnoDB: Doing recovery: scanned up to log sequence number 0 178032128 InnoDB: Doing recovery: scanned up to log sequence number 0 178097664 InnoDB: Doing recovery: scanned up to log sequence number 0 178163200 InnoDB: Doing recovery: scanned up to log sequence number 0 178228736 InnoDB: After this prints a line for every 10th scan sweep: InnoDB: Doing recovery: scanned up to log sequence number 0 178884096 ... InnoDB: Doing recovery: scanned up to log sequence number 0 193302016 InnoDB: Doing recovery: scanned up to log sequence number 0 193957376 InnoDB: Doing recovery: scanned up to log sequence number 0 194612736 020204 23:08:40 InnoDB: Starting an apply batch of log records to the database. .. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 0 195268096 InnoDB: Doing recovery: scanned up to log sequence number 0 195923456 ... InnoDB: Doing recovery: scanned up to log sequence number 0 203132416 InnoDB: Doing recovery: scanned up to log sequence number 0 203787776 InnoDB: Doing recovery: scanned up to log sequence number 0 204443136 InnoDB: 5 uncommitted transaction(s) which must be rolled back InnoDB: Trx id counter is 0 129792 InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx with id 0 129400 InnoDB: Rolling back of trx id 0 129400 completed InnoDB: Rolling back trx with id 0 129217 InnoDB: Rolling back of trx id 0 129217 completed InnoDB: Rolling back trx with id 0 129098 InnoDB: Rolling back of trx id 0 129098 completed InnoDB: Rolling back trx with id 0 128743 InnoDB: Rolling back of trx id 0 128743 completed InnoDB: Rolling back trx with id 0 127939 InnoDB: Rolling back of trx id 0 127939 completed InnoDB: Rollback of uncommitted transactions completed 020204 23:08:51 InnoDB: Starting an apply batch of log records to the database. .. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file offset 0 40418561, file name ./donna-bin.001 020204 23:08:53 InnoDB: Flushing modified pages from the buffer pool... 020204 23:09:03 InnoDB: Started mysqld: ready for connections

如果資料庫遭到損壞或失敗，則不得不從一個備份檔案恢復。在損壞的情況下，首先可以恢復一個未損壞的備份檔案。然後依照 MySQL 手冊提示從一般的日誌檔案中恢復資料。

在某些資料庫損壞的情況下，可能透過轉儲(dump)、撤銷(drop)和重新建立一個或多個損壞的表就足夠了。可憐透過 CHECK TABLE SQL 命令檢查一個受損的表，雖然 CHECK TABLE 並不能發現所有的損壞型別。你可能使用 innodb_tablespace_monitor 來檢查資料檔案時的檔案空間管理的完整性。

在某些情況下，資料庫頁面顯示損壞，而實際上是由於操作的檔案高速緩衝損壞，而磁碟上的資料檔案還是好的。 這時最好先重起你的系統。這可能解決資料庫頁面錯誤。

如果出現資料庫頁面損壞，可以透過 INTO OUTFILE 從資料庫中轉儲出表資料，通常大部分的資料並未受損壞。 但是這些損壞可能引起 SELECT * FROM table 或 InnoDB 後臺操作崩潰或中斷(assert)，甚至是 InnoDB 的前滾(roll-forward)恢復崩潰。從 InnoDB version 3.23.44 開始，在 my.cnf 中有個設定選項可以強制 InnoDB 啟動，以及防止後臺操作的執行，因而你可以轉儲資料。例如，你可以 my.cnf 在中加入如下設定：

set-variable = innodb_force_recovery = 4

　

innodb_force_recovery 代替選擇將在下面列出。 這個引數不能用於資料庫的其它方面！當設定值大於 0 時，作為安全尺度，InnoDB 禁止使用 INSERT, UPDATE, 或 DELETE 。

從 3.23.53 和 4.0.4 開始，即使強制恢復被使用你也可以使用 DROP 或 CREATE 一個表。 如果你確定表如引起回滾崩潰，你可以移除(drop)它。你也可以透過這個停止一個因匯入大量資料或 ALTER TABLE 而引起的失控(runaway)回滾。你可以殺死 mysqld 程式，並使用 my.cnf 設定項 innodb_force_recovery=3 不使用回滾。然後就可以 DROP 那個引起失控(runaway)回滾的表。

下面較大的數意味著包含所有較低數所對就的安全防範。為了能夠轉儲表設定至少為 4 ，這是相對安全的，僅僅只有一些損壞的頁面資料掉失。Option 6 is more dramatic, because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures.

• 1 (SRV_FORCE_IGNORE_CORRUPT) 即使發現一個錯誤也啟動服務；試著使用 SELECT * FROM table 跳過損壞的記錄和頁面，這將幫助轉儲表。
• 2 (SRV_FORCE_NO_BACKGROUND) prevent the main thread from running: 如果在清理過程中將發生崩潰，這將預防它。
• 3 (SRV_FORCE_NO_TRX_UNDO) 恢復時不執行事務回滾。
• 4 (SRV_FORCE_NO_IBUF_MERGE) 防止插入緩衝區的歸併操作：如果他們將引起崩潰，最好不要操作他們；不要考慮表統計(table statistics)。
• 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) 當啟動資料庫時不撤銷日誌(undo logs)：InnoDB 將未完成的事務已提交。
• 6 (SRV_FORCE_NO_LOG_REDO) do not do the log roll-forward in connection with recovery.

　

InnoDB 透過一個模糊的檢查點來實現檢查點機制。InnoDB 以很小的批次從緩衝池中重新整理修改了的資料庫頁面。這就不需要在一個批次中重新整理整個緩衝池，因這個實話上將可能停止使用者 SQL 語句執行程式一段時間。

In crash recovery InnoDB 在崩潰修復時會檢查記錄在日誌檔案中的檢查點標籤。它知道，在標籤前所有對資料庫的修改已被記錄到資料庫的磁碟映象中。然後 InnoDB 掃描日誌檔案中檢查點後面的日誌並將修改記入資料庫。

InnoDB 以一個環形方式記錄日誌檔案。所有使緩衝池中的資料庫頁面與磁碟映象不相同已提交了的修改必須記錄在日誌檔案中，以防 InnoDB 需要恢復。 這就意味著 InnoDB 以環形方式重新啟用一個日誌檔案，它必須確定將被重新使用的日誌檔案中的操作日誌結果已被磁碟映象檔案包含。用另一句話來說就是，InnoDB 必須時常地建立檢查點並將修改了的資料庫頁面到磁碟中。

上面所述要以解釋為什麼將日誌檔案設定和大一點可以減少因建立檢查點所用的磁碟 I/O。 這就可以理解設定日誌檔案的總尺寸與緩衝池一樣大或更大。大的日誌檔案的缺點就是當進行崩潰修復時將需要很長的時間，因為有更多的操作日誌需要更新到資料庫中。