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

但谷歌搜索表明这些都很好。

副本是由运行 pg_basebackup 使用 repmgr 创建的，用于执行克隆，然后启动副本并看到它赶上来。这以前是与 Postgres 10 一起使用的。

关于为什么这个副本出现但永远滞后的任何想法？

Answer 1

我仍然不确定问题是什么 is/was，但我能够让备用数据库赶上这两个更改：

在 repmgr 配置中设置 use_replication_slots=true
在 postgres 配置中设置 wal_compression=on

除了使 replication_delay_gbytes 大致保持平稳之外，使用复制槽似乎没有任何改变。以某种方式启用 WAL 压缩确实有所帮助，尽管我不完全确定如何。是的，理论上它可以更快地将 WAL 文件发送到备用服务器，但是查看网络日志我发现 sent/received 字节的下降与压缩效果相匹配，因此它似乎同时发送 WAL 文件使用更少的网络速度。

这里似乎仍然存在一些潜在的问题，因为例如当我 pg_basebackup 创建备用时，它会产生大约 500 MB/s 的网络流量，但是当它在备用完成恢复后流式传输 WAL 时，它在没有 WAL 压缩的情况下下降到 ~250 MB/s，在 WAL 压缩下下降到 ~100 MB/s，但是在它赶上 WAL 压缩后网络流量没有减少，所以我不确定那里发生了什么让它赶上来。

Postgres 11 Standby 永远赶不上

Postgres 11 Standby never catches up

postgresql

database-replication

wal

postgresql-11