30.5.?WAL內(nèi)部

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

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

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

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

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

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

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

本文轉(zhuǎn)自PostgreSQL中文社區(qū)，原文鏈接：30.5.?WAL內(nèi)部

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。