Postgres 11 Standby永不追趕

Question

由於升級到Postgres 11，我無法趕上生產備用服務器。 在日志中，最終看起來一切正常：

2019-02-06 19:23:53.659 UTC [14021] LOG:  consistent recovery state reached at 3C772/8912C508
2019-02-06 19:23:53.660 UTC [13820] LOG:  database system is ready to accept read only connections
2019-02-06 19:23:53.680 UTC [24261] LOG:  started streaming WAL from primary at 3C772/8A000000 on timeline 1

但是以下查詢顯示一切都不理想：

warehouse=# SELECT coalesce(abs(pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn())), -1) / 1024 / 1024 / 1024 AS replication_delay_gbytes;
 replication_delay_gbytes
-------------------------
    208.2317776754498486
(1 row)

warehouse=# select now() - pg_last_xact_replay_timestamp() AS replication_delay;
 replication_delay
-------------------
 01:54:19.150381
(1 row)

一會兒（幾個小時）后， replication_delay保持不變，但replication_delay_gbytes增長了，盡管請注意， replication_delay從一開始就落后了，而且replication_delay_gbytes從0開始。 在啟動過程中，出現了許多以下消息：

2019-02-06 18:24:36.867 UTC [14036] WARNING:  xlog min recovery request 3C734/FA802AA8 is past current point 3C700/371ED080
2019-02-06 18:24:36.867 UTC [14036] CONTEXT:  writing block 0 of relation base/16436/2106308310_vm

但谷歌搜索表明這些很好。

副本是使用repmgr通過運行pg_basebackup來執行克隆，然后啟動副本並看到其趕上來創建的。 以前是使用Postgres 10。

關於此副本為何出現但永久滯后的任何想法？

Answer 1

我仍然不確定問題是什么，還是什么，但是我能夠使備用數據庫適應以下兩個更改：

• 在repmgr配置中設置use_replication_slots=true
• 在postgres配置中設置wal_compression=on

使用復制插槽似乎並沒有什么改變，只是使replication_delay_gbytes大致保持不變。 雖然我不確定如何壓縮WAL壓縮，但確實有所幫助。 是的，從理論上講，它可以更快地將WAL文件傳送到備用數據庫，但是查看網絡日志時，我發現發送/接收的字節數下降了，這與壓縮的效果相匹配，因此似乎可以以相同的速度傳送WAL文件。使用更少的網絡。

但是，這里似乎仍然存在一些潛在的問題，因為例如當我執行pg_basebackup創建備用數據庫時，它會生成大約500 MB / s的網絡流量，但是當備用數據庫完成恢復后，它正在流式傳輸WAL時在沒有WAL壓縮的情況下下降到〜250 MB / s，在具有WAL壓縮的情況下下降到〜100 MB / s，但是在趕上WAL壓縮之后網絡流量沒有減少，因此我不確定在那里發生了什么事情跟上來。