PostgreSQL 10.0 preview 功能增強 - WAL一緻性校驗

postgresql , 10.0 , wal , wal_consistency_checking

10.0 新增了一個debug參數，用于檢測recovery過程中，由于wal replay bug或者備庫的實體資料塊異常導緻的wal replay回放出來的塊不正确的問題。

當産生髒頁時，在wal記錄中，可能有兩種資訊：

1. 隻記錄了資料變更的部分。

2. full page，記錄了整個資料塊。(發生時機：當開啟了full page write參數，checkpoint後第一次變更的塊)

在postgresql進入恢複過程（或者standby）時，postgresql startup程序會從wal日志中讀取wal record與資料檔案的塊進行回放組合，生成變更後的塊。如果wal是full page，則直接使用full page。回放後的塊覆寫老的資料塊，實作恢複的目的。

但是有可能因為各種原因，導緻回放後的資料塊是不對的，比如前面提到的原因：（由于wal replay bug或者備庫的實體資料塊異常導緻的wal replay回放出來的塊不正确）。

postgresql 10.0新增的wal_consistency_checking參數，可以用于發現這種問題。

為什麼postgresql 10.0要加這個參數呢？

因為postgresql的擴充功能極強，已經支援了wal generic record，也就是說，使用者可以自定義往wal中寫資料，開放這樣的功能，有利于開發者調試自己擴充的wal generic writer的正确性。

wal_consistency_checking 參數可以設定為如下值：

參數内容表示當主庫産生wal對應的resource manger record時，自動将當時髒頁的full page寫入wal中。在startup程序回放日志時，會比較 "這個full page" 與 "wal partial record+data page replay出來的page" 是否一緻，如果不一緻，說明wal回放有問題。startup 程序将會fatal，停止恢複。

對于正常的差異（例如hint bit）是不會報錯的。

<a href="https://github.com/digoal/blog/blob/master/201509/20150905_01.md">《為什麼postgresql查詢語句也可能産生 xlog， 并且可能對buffer有write操作 ? hint bits》</a>

這個patch的讨論，詳見郵件組，本文末尾url。

postgresql社群的作風非常嚴謹，一個patch可能在郵件組中讨論幾個月甚至幾年，根據大家的意見反複的修正，patch合并到master已經非常成熟，是以postgresql的穩定性也是遠近聞名的。

<a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a507b86900f695aacc8d52b7d2cfcb65f58862a2">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a507b86900f695aacc8d52b7d2cfcb65f58862a2</a>

<a href="https://www.postgresql.org/docs/devel/static/runtime-config-developer.html">https://www.postgresql.org/docs/devel/static/runtime-config-developer.html</a>