PostgreSQL WAL內(nèi)部

WAL是自動被啟用的。除了確保滿足WAL日志存放所需要的磁盤空間以及一些必要的調(diào)優(yōu)外（參閱第 29.4 節(jié)），管理員無需執(zhí)行任何操作。

當每個新記錄被寫入時，WAL記錄被追加到WAL日志中。 插入位置由日志序列號（LSN）描述，該日志序列號是日志中的字節(jié)偏移量， 隨每個新記錄單調(diào)遞增。LSN值作為數(shù)據(jù)類型 pg_lsn返回。 值可以進行比較以計算分離它們的WAL數(shù)據(jù)量，因此它們用于衡量復制和恢復的進度。

WAL日志被存放在數(shù)據(jù)目錄的pg_wal目錄里，它是作為一個文件段的集合存儲的，通常每個段16MB大?。ú贿^這個大小可以通過initdb配置選項--with-wal-segsize來修改）。每個段分割成多個頁，通常每個頁為8K（該尺寸可以通過--with-wal-blocksize配置選項來修改）。日志記錄頭部在 access/xlogrecord.h里描述；日志內(nèi)容取決于它記錄的事件類型。段文件的名字是不斷增長的數(shù)字，從000000010000000000000001開始。目前這些數(shù)字不能回卷，不過要把所有可用的數(shù)字都用光也需要非常非常長的時間。

日志被放置在和主數(shù)據(jù)庫文件不同的另外一個磁盤上會比較好。你可以通過把pg_wal目錄移動到另外一個位置（當然在此期間服務器應當被關閉），然后在原來的位置上創(chuàng)建一個指向新位置的符號鏈接來實現(xiàn)重定位日志。

WAL的目的是確保在數(shù)據(jù)庫記錄被修改之前先寫了日志，但是這可能會被那些謊稱向內(nèi)核寫成功的 破壞， 這時候它們實際上只是緩沖了數(shù)據(jù)而并未把數(shù)據(jù)存儲到磁盤上。 這種情況下的電源失效仍然可能導致不可恢復的數(shù)據(jù)崩潰。 管理員應該確保保存PostgreSQL的WAL日志文件的磁盤不會做這種謊報（參見第 29.1 節(jié)）。

在完成一個檢查點并且刷寫了日志文件之后，檢查點的位置被保存在文件pg_control里。因此在恢復的開始， 服務器首先讀取pg_control，然后讀取檢查點記錄； 接著它通過從檢查點記錄里標識的日志位置開始向前掃描執(zhí)行 REDO操作。 因為數(shù)據(jù)頁的所有內(nèi)容都保存在檢查點之后的第一個頁面修改的日志里（假設full_page_writes沒有被禁用）， 所以自檢查點以來的所有變化的頁都將被恢復到一個一致的狀態(tài)。

為了處理pg_control被損壞的情況， 我們應該支持對于現(xiàn)有日志段反向掃描的功能 — 從最新到最老 — 這樣才能找到最后的檢查點。但這些目前還沒有被實現(xiàn)。pg_control很?。ū纫粋€磁盤頁小），因此它不會出現(xiàn)頁斷裂問題， 并且到目前為止還沒有發(fā)現(xiàn)僅僅由于無法讀取pg_control本身導致數(shù)據(jù)庫失敗的報告。 因此，盡管這在理論上是一個薄弱環(huán)節(jié)，但是 pg_control看起來似乎并不是實際會發(fā)生的問題。