PG的延遲複製及相關參數的設置影響

說明： 下文的部份內容節選自《PostgreSQL實戰》

PG的延遲複製

參數： recovery_min_apply_delay

 

某些狀況下，一個後備服務器會盡快恢復來自於主服務器的 WAL 記錄。有一份數據的延時拷貝是有用的，它能提供機會糾正數據丟失錯誤。這個參數容許你將恢復延遲一段固定的時間，若是沒有指定單位則以毫秒爲單位。例如，若是你設置這個參數爲5min，對於一個事務提交，只有當後備機上的系統時鐘超過主服務器報告的提交時間至少 5分鐘時，後備機纔會重放該事務。

 

有可能服務器之間的複製延遲會超過這個參數的值，在這種狀況下則不會增長延遲。注意延遲是根據主服務器上寫 WAL 的時間戳以及後備機上的當前時間來計算。因爲網絡延遲或者級聯複製配置致使的傳輸延遲可能會顯著地減小實際等待時間。若是主服務器和後備機上的系統時鐘不一樣步，這會致使恢復比預期的更早應用記錄。但這不是一個主要問題，由於這個參數有用的設置比服務器之間的典型事件誤差要大得多。

 

只有在事務提交的 WAL 記錄上纔會發生延遲。其餘記錄仍是會被儘量快地重放，這不會成爲問題，由於 MVCC 可見性規則確保了在對應的提交記錄被應用以前它們的效果不會被看到。

 

一旦恢復中的數據庫已經達到一致狀態，延遲就會產生，直到後備機被提高或者觸發。在那以後，後備機將會結束恢復而且再也不等待。

 

這個參數的目的是和流複製部署一塊兒使用，可是，若是指定了該參數，全部的狀況下都會遵照它。使用這個特性也會讓hot_standby_feedback被延遲，這可能致使主服務器的膨脹，二者一塊兒使用時要當心。

 

 

延遲備庫的搭建很簡單， 只要在 recovery.conf 裏面增長個配置項便可

recovery_min_apply_delay = 1min  # 這裏我測試就設置1分鐘的延遲

## 默認的支持時間單位爲 ms 、s、min、h、d 即 毫秒 秒 分鐘 小時 天

 

注意：修改後，須要重啓 standby節點才能生效。

 

 

 

而後，在主庫建立表並插入一條測試數據：

postgres=# create table test_delay(id int4,create_time timestamp(0) without time zone);

postgres=# insert into test_delay (id,create_time) values (1,now());

 

而後，等一分鐘左右到延遲standby節點去查看下數據是否同步過去

 

 

延遲複製場景下 recovery_min_apply_delay 參數對同步複製的影響

同步複製狀況下， 一般要 synchronous_commit 配置爲 on 或 remote_apply

on 表示 standby將wal接收到 --> 寫入wal日誌文件 --> 向客戶端返回成功。

standby表示 standby將wal接收到 --> 寫入wal日誌文件 --> 並應用到standby --> 纔會向客戶端返回成功。

 

 

下面對 synchronous_commit 不一樣參數下，而且設置了延遲複製的測試：

 

場景1： synchronous_commit=on  而且 recovery_min_apply_delay = 1min

注意：

synchronous_commit是設置在主庫的postgresql.conf中的(支持會話級別設置,也能夠修改配置文件reload後全局生效)。

recovery_min_apply_delay 是設置在standby的recovery.conf中的。

 

這種場景下， 咱們在主庫上插入一條數據，主庫會當即返回執行成功or失敗的結果。 而後咱們到延遲複製的standby去查詢，發現仍是會須要1min後才能查到這條數據。

也就是說， 延遲備庫場景下， synchronous_commit 配置爲on時 和 異步流複製是一致的。

 

 

 

 

場景2： synchronous_commit=remote_apply  而且 recovery_min_apply_delay = 1min

注意：

synchronous_commit是設置在主庫的postgresql.conf中的(支持會話級別設置,也能夠修改配置文件reload後全局生效)。

recovery_min_apply_delay 是設置在standby的recovery.conf中的。

 

這種場景下， 咱們在主庫上插入一條數據，主庫會hang住等待1min(等待從庫完成apply操做)後，而後才能返回執行成功or失敗的結果。

而後咱們到延遲複製的standby去查詢，發現當即就能查到這條數據。

 

也就是說， 延遲備庫場景下， synchronous_commit 配置爲 remote_apply時，會形成主庫上面的事務的提交的阻塞。

生產環境用到延遲從庫的場景下，必定要避免設置 synchronous_commit=remote_apply (固然從性能角度考慮也不多會設置爲remote_apply的)