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从{{ 1}}。在启动过程中，有许多消息：

但是谷歌搜索显示这些很好。

Replica是使用repmgr创建的，方法是运行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来执行克隆，然后启动副本并查看副本。这以前是与Postgres 10一起使用的。

是否有任何关于为什么出现此副本但永久滞后的想法？

Answer 1

我仍然不确定是什么问题，但是我能够使备用服务器适应以下两个更改：

设置ProcessFrame
设置use_replication_slots=true

使用复制插槽似乎除了使wal_compression=on大致保持不变外没有改变。虽然我不确定如何压缩WAL压缩，但确实有所帮助。是的，从理论上讲，它可以更快地将WAL文件传送到备用数据库，但是查看网络日志时，我发现发送/接收的字节数下降了，这与压缩的效果相匹配，因此似乎可以以相同的速度传送WAL文件。使用更少的网络。

尽管如此，这里似乎仍然存在一些潜在的问题，因为例如，当我执行replication_delay_gbytes创建备用数据库时，它将产生大约500 MB / s的网络流量，但是当它流传输时待机完成恢复后的WAL，在没有WAL压缩的情况下下降到〜250 MB / s，在WAL压缩的情况下下降到〜100 MB / s，但是在赶上WAL压缩之后网络流量没有减少，所以我不确定是什么在那里继续赶上它。

Postgres 11 Standby永不追赶

1 个答案: