Chapter 25. 預寫式日誌(Write-Ahead Logging (WAL))

Table of Contents
25.1. WAL 的好處
25.2. WAL 配置
25.3. 內部

預寫式日誌WAL) 是一種實現交易日誌的標準方法。有關它的詳細描述可以在大多數(如果不是全部的話)有關交易處理的書中找到。 簡而言之,WAL 的中心思想是對資料文件的修改(它們是資料表和索引的載體)必須是只能發生在這些修改已經記錄了日誌之後, 也就是說,在描述這些變化的日誌記錄沖刷到永久儲存器之後。 如果我們遵循這個過程,那麼我們就不需要在每次交易提交的時候都把資料頁沖刷到磁盤,因為我們知道在出現崩潰的情況下, 我們可以用日誌來恢復資料庫:任何尚未附加到資料頁的記錄都將先從日誌記錄中重做(這叫向前滾動恢復,也叫做 REDO)。

25.1. WAL 的好處

使用 WAL 的第一個主要的好處就是顯著地減少了磁盤寫的次數。 因為在日誌提交的時候只有日誌文件需要沖刷到磁盤;而不是交易修改的所有資料文件。 在多用戶環境裡,許多交易的提交可以用日誌文件的一次 fsync() 來完成。而且,日誌文件是順序寫的, 因此同步日誌的開銷要遠比同步資料頁的開銷要小。 這一點對於許多小交易修改資料儲存的許多不同的位置更是如此。

另外一個好處就是資料頁的完整性。實際情況是,在 WAL 之前,PostgreSQL 從來不能保證在崩潰的情況下資料頁的完整性。 在 WAL 之前,在寫的過程中的任何崩潰都可能導致:

  1. 索引記錄指向一個不存在的資料表的行

  2. 索引記錄在分裂操作中丟失

  3. 完全崩潰了的資料表和索引頁的內容,因為資料頁只寫了一部分

索引的問題(問題 1 和 2)可能已經透過額外的 fsync 調用修補好了,但是如果沒有 WAL,那麼沒有很明顯的處理第三種情況的方法; WAL 在日誌裡保存整個資料頁的內容 -- 如果那些內容在崩潰後的恢復中需要確保資料頁的完整性的話。

最後,WAL 還提供了資料庫在線備份和恢復(backup and restore (BAR))的可能, 就像 Section 22.3 裡描述的那樣。 透過歸檔的 WAL 文件,我們可以支援恢復到手頭的 WAL 文件包含的任意時刻: 我們只需要簡單地安裝以前的資料庫的實際備份,然後重放 WAL 到自己希望的時間。 另外,實際備份還不必是資料庫狀態的一個即時快照 — 如果它是花了一段時間製作的話, 因為 WAL 日誌的重放將修復任何內部的不一致。