PG的延遲復(fù)制及相關(guān)參數(shù)的設(shè)置影響

說明： 下文的部分內(nèi)容節(jié)選自《PostgreSQL實戰(zhàn)》

PG的延遲復(fù)制

參數(shù)： recovery_min_apply_delay

?

某些情況下，一個后備服務(wù)器會盡快恢復(fù)來自于主服務(wù)器的 WAL 記錄。有一份數(shù)據(jù)的延時拷貝是有用的，它能提供機會糾正數(shù)據(jù)丟失錯誤。這個參數(shù)允許你將恢復(fù)延遲一段固定的時間，如果沒有指定單位則以毫秒為單位。例如，如果你設(shè)置這個參數(shù)為5min，對于一個事務(wù)提交，只有當(dāng)后備機上的系統(tǒng)時鐘超過主服務(wù)器報告的提交時間至少 5分鐘時，后備機才會重放該事務(wù)。

?

有可能服務(wù)器之間的復(fù)制延遲會超過這個參數(shù)的值，在這種情況下則不會增加延遲。注意延遲是根據(jù)主服務(wù)器上寫 WAL 的時間戳以及后備機上的當(dāng)前時間來計算。由于網(wǎng)絡(luò)延遲或者級聯(lián)復(fù)制配置導(dǎo)致的傳輸延遲可能會顯著地減少實際等待時間。如果主服務(wù)器和后備機上的系統(tǒng)時鐘不同步，這會導(dǎo)致恢復(fù)比預(yù)期的更早應(yīng)用記錄。但這不是一個主要問題，因為這個參數(shù)有用的設(shè)置比服務(wù)器之間的典型事件偏差要大得多。

?

只有在事務(wù)提交的 WAL 記錄上才會發(fā)生延遲。其他記錄還是會被盡可能快地重放，這不會成為問題，因為 MVCC 可見性規(guī)則確保了在對應(yīng)的提交記錄被應(yīng)用之前它們的效果不會被看到。

?

一旦恢復(fù)中的數(shù)據(jù)庫已經(jīng)達(dá)到一致狀態(tài)，延遲就會產(chǎn)生，直到后備機被提升或者觸發(fā)。在那之后，后備機將會結(jié)束恢復(fù)并且不再等待。

?

這個參數(shù)的目的是和流復(fù)制部署一起使用，但是，如果指定了該參數(shù)，所有的情況下都會遵守它。使用這個特性也會讓hot_standby_feedback被延遲，這可能導(dǎo)致主服務(wù)器的膨脹，兩者一起使用時要小心。

?

?

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

recovery_min_apply_delay = 1min? # 這里我測試就設(shè)置1分鐘的延遲

## 默認(rèn)的支持時間單位為 ms 、s、min、h、d 即 毫秒 秒 分鐘 小時 天

?

注意：修改后，需要重啟 standby節(jié)點才能生效。

?

?

?

然后，在主庫創(chuàng)建表并插入一條測試數(shù)據(jù)：

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節(jié)點去查看下數(shù)據(jù)是否同步過去

?

?

延遲復(fù)制場景下 recovery_min_apply_delay 參數(shù)對同步復(fù)制的影響

同步復(fù)制情況下， 通常要 synchronous_commit 配置為 on 或 remote_apply

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

standby表示 standby將wal接收到 --> 寫入wal日志文件 --> 并應(yīng)用到standby --> 才會向客戶端返回成功。

?

?

下面對 synchronous_commit 不同參數(shù)下，并且設(shè)置了延遲復(fù)制的測試：

?

場景1： synchronous_commit=on? 并且 recovery_min_apply_delay = 1min

注意：

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

recovery_min_apply_delay 是設(shè)置在standby的recovery.conf中的。

?

這種場景下， 我們在主庫上插入一條數(shù)據(jù)，主庫會立即返回執(zhí)行成功or失敗的結(jié)果。 然后我們到延遲復(fù)制的standby去查詢，發(fā)現(xiàn)還是會需要1min后才能查到這條數(shù)據(jù)。

也就是說， 延遲備庫場景下， synchronous_commit 配置為on時 和 異步流復(fù)制是一致的。

?

?

?

?

場景2： synchronous_commit=remote_apply? 并且 recovery_min_apply_delay = 1min

注意：

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

recovery_min_apply_delay 是設(shè)置在standby的recovery.conf中的。

?

這種場景下， 我們在主庫上插入一條數(shù)據(jù)，主庫會hang住等待1min(等待從庫完成apply操作)后，然后才能返回執(zhí)行成功or失敗的結(jié)果。

然后我們到延遲復(fù)制的standby去查詢，發(fā)現(xiàn)立即就能查到這條數(shù)據(jù)。

?

也就是說， 延遲備庫場景下， synchronous_commit 配置為 remote_apply時，會造成主庫上面的事務(wù)的提交的阻塞。

生產(chǎn)環(huán)境用到延遲從庫的場景下，一定要避免設(shè)置 synchronous_commit=remote_apply (當(dāng)然從性能角度考慮也很少會設(shè)置為remote_apply的)

?

?

?