支援的版本: 目前版本 (17) / 16 / 15 / 14 / 13
開發版本: devel
不支援的版本: 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1

28.3. 預寫式日誌 (WAL) #

預寫式日誌 (WAL) 是一種確保資料完整性的標準方法。在大多數(如果不是全部)關於交易處理的書籍中都可以找到詳細的描述。簡而言之,WAL的核心概念是,對資料檔案(表格和索引所在的位置)的變更必須僅在這些變更被記錄之後才能寫入,也就是說,在描述變更的 WAL 記錄被刷新到永久儲存體之後。如果我們遵循此程序,我們就不需要在每次交易提交時將資料頁面刷新到磁碟,因為我們知道,如果發生崩潰,我們將能夠使用日誌恢復資料庫:任何尚未應用於資料頁面的變更都可以從 WAL 記錄中重新執行。(這就是前滾恢復,也稱為 REDO。)

提示

由於WAL會在崩潰後恢復資料庫檔案內容,因此不需要日誌式檔案系統來可靠地儲存資料檔案或 WAL 檔案。事實上,日誌記錄的開銷會降低效能,特別是如果日誌記錄導致檔案系統 資料 被刷新到磁碟。幸運的是,通常可以使用檔案系統掛載選項來停用日誌記錄期間的資料刷新,例如,Linux ext3 檔案系統上的 data=writeback。日誌式檔案系統確實可以提高崩潰後的啟動速度。

使用WAL會顯著減少磁碟寫入的次數,因為只需要將 WAL 檔案刷新到磁碟,就可以保證交易已提交,而不是由交易變更的每個資料檔案。 WAL 檔案是循序寫入的,因此同步 WAL 的成本遠低於刷新資料頁面的成本。對於處理許多觸及資料儲存不同部分的小型交易的伺服器來說,尤其如此。此外,當伺服器正在處理許多小型並行交易時,一個 fsync 的 WAL 檔案可能足以提交許多交易。

WAL也使得支援線上備份和時間點恢復成為可能,如 第 25.3 節 中所述。透過封存 WAL 資料,我們可以支援恢復到可用 WAL 資料涵蓋的任何時間點:我們只需安裝資料庫的先前實體備份,並將 WAL 重播到所需的時間即可。更重要的是,實體備份不必是資料庫狀態的即時快照 — 如果它是在一段時間內製作的,那麼重播該期間的 WAL 將修復任何內部不一致。

提交更正

如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的地方,請使用 此表單 報告文件問題。