文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (美式信紙) - 40.0Mb
PDF (A4) - 40.1Mb
手冊頁 (TGZ) - 258.2Kb
手冊頁 (Zip) - 365.3Kb
資訊 (Gzip) - 4.0Mb
資訊 (Zip) - 4.0Mb


17.18.2 InnoDB 復原

本節說明 InnoDB 復原。主題包括

時間點復原

若要將 InnoDB 資料庫從實體備份製作的時間復原到目前時間,您必須在進行備份之前就啟用二進位記錄來執行 MySQL 伺服器。若要還原備份後達到時間點復原,您可以套用從備份製作後發生的二進位記錄變更。請參閱第 9.5 節,「時間點(增量)復原」

從資料損毀或磁碟故障復原

如果您的資料庫損毀或發生磁碟故障,您必須使用備份執行復原。如果發生損毀,請先找到未損毀的備份。還原基本備份後,使用 mysqlbinlogmysql 從二進位記錄檔執行時間點復原,以還原備份製作後發生的變更。

在某些資料庫損毀案例中,傾印、捨棄和重新建立一個或幾個損毀的資料表就足夠了。您可以使用 CHECK TABLE 陳述式檢查資料表是否損毀,雖然 CHECK TABLE 自然無法偵測每種可能的損毀類型。

在某些情況下,表面上的資料庫頁面損毀實際上是因為作業系統損毀了其本身的檔案快取,而且磁碟上的資料可能沒問題。最好先嘗試重新啟動電腦。這麼做可能會消除似乎是資料庫頁面損毀的錯誤。如果 MySQL 因為 InnoDB 一致性問題而仍然難以啟動,請參閱第 17.20.3 節,「強制 InnoDB 復原」,以取得在復原模式下啟動執行個體的步驟,這允許您傾印資料。

InnoDB 當機復原

若要從非預期的 MySQL 伺服器結束中復原,唯一的要求是重新啟動 MySQL 伺服器。InnoDB 會自動檢查日誌並將資料庫向前滾動到目前時間。InnoDB 會自動回滾當機時存在的未提交交易。

InnoDB 當機復原包含數個步驟

  • 表格空間探索

    表格空間探索是 InnoDB 用來識別需要重做日誌應用程式的表格空間的程序。請參閱當機復原期間的表格空間探索

  • 重做日誌應用程式

    在初始化期間,也就是在接受任何連線之前,會執行重做日誌的應用。如果所有變更在關機或當機時,都已從緩衝池刷新到表空間ibdata**.ibd 檔案),則會跳過重做日誌的應用。InnoDB 如果在啟動時發現重做日誌檔案遺失,也會跳過重做日誌的應用。

    • 目前的自動遞增計數器最大值會在每次值變更時寫入重做日誌,這使其具備當機安全 (crash-safe) 性。在復原期間,InnoDB 會掃描重做日誌以收集計數器值變更,並將變更套用至記憶體中的表格物件。

      如需有關 InnoDB 如何處理自動遞增值的詳細資訊,請參閱第 17.6.1.6 節,「InnoDB 中的 AUTO_INCREMENT 處理」以及InnoDB AUTO_INCREMENT 計數器初始化

    • 當遇到索引樹狀結構損毀時,InnoDB 會將損毀標記寫入重做日誌,這使得損毀標記具備當機安全 (crash-safe) 性。InnoDB 還會在每個檢查點將記憶體中的損毀標記資料寫入引擎專用的系統表格。在復原期間,InnoDB 會從這兩個位置讀取損毀標記,並在將記憶體中的表格和索引物件標示為損毀之前合併結果。

    • 不建議移除重做日誌以加快復原速度,即使可以接受一些資料遺失也是如此。只有在執行乾淨關機且innodb_fast_shutdown 設定為 01 之後,才應考慮移除重做日誌。

  • 不完整交易回溯

    不完整交易是指在發生非預期結束或快速關機時處於作用中的任何交易。回溯不完整交易所需的時間,可能是交易中斷前作用中時間的三到四倍,具體取決於伺服器負載。

    您無法取消正在回溯的交易。在極端情況下,如果預期回溯交易會花費非常長的時間,則使用 innodb_force_recovery 設定為 3 或更高的值啟動 InnoDB 可能會更快。請參閱第 17.20.3 節,「強制 InnoDB 復原」

  • 變更緩衝區合併

    當索引頁面讀取到緩衝池時,將變更從變更緩衝區(系統表空間的一部分)套用至次級索引的分葉頁面。

  • 清除

    刪除不再對作用中交易可見的已標示為刪除的記錄。

重做日誌應用之後的步驟不依賴重做日誌(除了用於記錄寫入之外),並且與正常處理並行執行。在這些步驟中,只有不完整交易的回溯是針對當機復原的特殊步驟。插入緩衝區合併和清除是在正常處理期間執行的。

在重做日誌應用之後,InnoDB 會盡快嘗試接受連線,以減少停機時間。作為當機復原的一部分,InnoDB 會回溯在伺服器結束時未提交或處於 XA PREPARE 狀態的交易。回溯由背景執行緒執行,並與來自新連線的交易並行執行。在完成回溯操作之前,新連線可能會遇到與已復原交易的鎖定衝突。

在大多數情況下,即使 MySQL 伺服器在繁重活動中意外終止,復原程序也會自動發生,而且 DBA 無需採取任何動作。如果硬體故障或嚴重的系統錯誤損毀了 InnoDB 資料,MySQL 可能會拒絕啟動。在這種情況下,請參閱第 17.20.3 節,「強制 InnoDB 復原」

如需有關二進位日誌和 InnoDB 當機復原的資訊,請參閱第 7.4.4 節,「二進位日誌」

當機復原期間的表空間探索

如果在復原期間,InnoDB 遇到自上次檢查點以來寫入的重做日誌,則必須將重做日誌應用於受影響的表空間。在復原期間識別受影響表空間的程序稱為表空間探索

表空間探索依賴於innodb_directories 設定,該設定定義在啟動時要掃描表空間檔案的目錄。innodb_directories 的預設設定為 NULL,但 innodb_data_home_dirinnodb_undo_directorydatadir 定義的目錄,在 InnoDB 建構要掃描的啟動目錄清單時,總是會附加到 innodb_directories 引數值。無論是否明確指定了 innodb_directories 設定,都會附加這些目錄。使用絕對路徑定義或位於附加到 innodb_directories 設定的目錄之外的表空間檔案,應新增到 innodb_directories 設定。如果在重做日誌中參考的任何表空間檔案先前未被探索到,則會終止復原。