30.5.?WAL內部

WAL是自動被啟用的。除了做一些設置滿足存放WAL日志的磁盤空間需求以及一些必要的調節以外（參閱第?30.4?節），對管理員沒有什么其他要求。

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

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

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

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

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

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

本文轉自PostgreSQL中文社區，原文鏈接：30.5.?WAL內部

總結

以上是生活随笔為你收集整理的PostgreSQL 10.1 手册_部分 III. 服务器管理_第 30 章 可靠性和预写式日志_30.5. WAL内部...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。