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压缩之后网络流量没有减少，因此我不确定在那里发生了什么事情跟上来。