PostgreSQL复制延迟调试

Question

我有一个由9.1个服务器组成的集群，运行流复制，并使用基于WAL-E的日志传送，以便在这方面落后。

一般来说，这是一个相当稳固的设置，不会落后，但是我们似乎在集群中有一个奴隶，在凌晨复制时总是落后。它总是在不久后又迎头赶上，但我至今还无法理解它为什么会这样做。

除了当我们的应用程序没有处理大量的负载时，在时间上似乎没有一致性。我是否可能因为缺乏可复制的数据而看到这种情况发生呢？

下面是postgresql.conf和recovery.conf的相关部分

postgresql.conf

archive_mode = on
archive_command = '. /mnt/data/postgresql/.profile && wal-e wal-push %p'

recovery.conf

recovery_target_timeline = 'latest'
standby_mode = 'on'
primary_conninfo = 'host=master_db_ip_address port=5432 user=postgres'
restore_command = '. /mnt/data/postgresql/.profile && wal-e wal-fetch "%f" "%p"'

为了添加更多的上下文，您可以看到，随着时间的推移，此服务器的复制延迟正在增加。

1. 这种情况不应发生。大多数情况下，流复制延迟应该小于1-2 s(根据过去使用该集群的经验)。
2. 在发生复制定时中的这些尖峰时，db集群上没有运行计划作业。

在调试这类问题时，有哪些好的策略？

编辑

我曾向我建议，我计算复制延迟的方法可能是不正确的，下面是我使用的方法：

SELECT EXTRACT(EPOCH FROM NOW() - pg_last_xact_replay_timestamp())

Answer 1

也许您正在体验以下文章末尾所描述的内容：

http://www.niwi.be/2013/02/16/replication-status-in-postgresql/

在一个非常繁忙的数据库中，每秒写很多次，这个数字将保持相当准确。但是，在很少写入的系统中，"replication_delay“将持续增长，因为上次重放的事务时间戳没有增加(这通常与MySQL的显示从状态输出相同)。