我想在 PostgreSQL 9.3 中使用流复制来测量将数据插入主表和从表之间的时间。为此，我创建了具有 2 个字段 id(serial)、t(text) 的表 test_time。之后添加了一个触发器：
cur_time:=to_char(current_timestamp, 'HH12:MI:SS:MS:US');
update test_time set t=cur_time where id=new.id;
但是两张表的时间是一样的。 如何测量延迟时间
【问题讨论】：
Alf162 在 Craig Ringer 的回答中提到了 cmets 中的一个很好的解决方案；所以我添加这个来澄清一下。
PostgreSQL 有一个管理函数pg_last_xact_replay_timestamp()，它返回在恢复期间重播的最后一个事务的时间戳。这是在主节点上生成该事务的提交或中止 WAL 记录的时间。
因此，副本上的此查询select now()-pg_last_xact_replay_timestamp() as replication_lag 将返回一个持续时间，该持续时间表示当前时钟与从复制流中应用的最后一条 WAL 记录的时间戳之间的时间差。
请注意，如果主节点没有接收到新的突变，则不会有 WAL 记录可供流式传输，并且以这种方式计算的延迟将会增加，而实际上并不是复制延迟的信号。如果主节点或多或少处于连续突变状态，它将持续流式传输 WAL，并且上述查询是对主节点上的更改在从节点上实现的时间延迟的精细近似。精度显然会受到两台主机上系统时钟同步的严格程度的影响。
【讨论】：
sent_lsn、replay_lsn 和 write_lsn 是更好的选择。时间的概念不是 PG 范畴内的东西。
您可以使用pg_xlog_location_diff 将主控端的pg_current_xlog_insert_location 与后端的pg_stat_replication 条目的replay_location 进行比较，很容易从主控端获得延迟以字节为单位。
这仅在主服务器上运行时有效。您不能从副本中执行此操作，因为副本不知道主节点领先多远。
此外，这不会告诉您延迟秒。在当前（至少从 9.4 开始）的 PostgreSQL 版本中，没有与提交或 WAL 记录关联的时间戳。所以没有办法知道给定的 LSN（xlog 位置）是多久以前的。
在当前 PostgreSQL 版本上以秒为单位获得副本延迟的唯一方法是让外部进程定期将 update 提交到专用时间戳表。因此，您可以将副本上的current_timestamp 与副本上可见的该表中最新条目的时间戳进行比较，以查看副本落后多远。这会创建额外的 WAL 流量，然后必须将这些流量保存在存档的 WAL 中以用于 PITR（PgBarman 或其他），因此您应该平衡增加的数据使用量和所需的延迟检测粒度。
PostgreSQL 9.5 可能会添加提交时间戳，有望让您了解给定提交发生了多长时间，以及副本在挂钟秒内落后了多长时间。
【讨论】：
pg_stat_replication 视图现在包含副本滞后作为时间（write_lag、flush_lag、replay_lag）：请参阅下面 Vao 的回答：stackoverflow.com/a/46662612/1128392
如果您的数据库频繁写入，则以下查询是获取从属延迟的近似值
select now() - pg_last_xact_replay_timestamp() AS replication_delay;
下面是一个更准确的查询，用于计算写入很少的数据库的复制延迟。如果主服务器没有向从服务器发送任何写入，那么 pg_last_xact_replay_timestamp() 可以是常量，因此可能无法使用上述查询准确地确定从服务器延迟。
SELECT CASE WHEN pg_last_xlog_receive_location() =
pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() -
pg_last_xact_replay_timestamp()) END AS log_delay;
【讨论】：
正确答案的版本略有不同：
postgres=# SELECT
pg_last_xlog_receive_location() receive,
pg_last_xlog_replay_location() replay,
(
extract(epoch FROM now()) -
extract(epoch FROM pg_last_xact_replay_timestamp())
)::int lag;
receive | replay | lag
------------+------------+-------
1/AB861728 | 1/AB861728 | 2027
只有当“接收”不等于“重播”时，延迟才重要。在副本上执行查询
【讨论】：
截至 10 版：
https://www.postgresql.org/docs/10/static/monitoring-stats.html#pg-stat-replication-view
write_lag interval 从本地刷新最近的 WAL 到接收到此备用服务器有通知之间经过的时间 写了它（但尚未刷新或应用它）。这可以用来 衡量 synchronous_commit 级别 remote_write 发生的延迟 如果此服务器配置为同步，则提交时 待机。
flush_lag interval 从本地刷新最近的 WAL 到接收到此备用服务器有通知之间经过的时间 写入并刷新它（但尚未应用它）。这可以用来 衡量 synchronous_commit 级别 remote_flush 发生的延迟 如果此服务器配置为同步，则提交时 待机。
replay_lag interval 从本地刷新最近的 WAL 到接收到该备用服务器有通知之间经过的时间 写入，刷新并应用它。这可以用来衡量延迟 提交时发生的 synchronous_commit 级别 remote_apply 如果此服务器配置为同步备用服务器。
（格式化我的）
唉，新列似乎只适合同步复制（否则 master 不会知道确切的延迟），因此异步复制延迟问题似乎仍然存在 now()-pg_last_xact_replay_timestamp()...
【讨论】：
对于postgresql 10 或更高版本（函数pg_last_xlog_receive_location() 和其他在这个版本中不存在），我使用这个：
SELECT
pg_is_in_recovery() AS is_slave,
pg_last_wal_receive_lsn() AS receive,
pg_last_wal_replay_lsn() AS replay,
pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() AS synced,
(
EXTRACT(EPOCH FROM now()) -
EXTRACT(EPOCH FROM pg_last_xact_replay_timestamp())
)::int AS lag;
如果您在 master 上运行此查询，结果将是：
is_slave | receive | replay | synced | lag
----------+---------+--------+--------+-----
f | | | |
(1 row)
如果你在同步的 slave 上运行这个查询，结果会是这样的：
is_slave | receive | replay | synced | lag
----------+-----------+-----------+--------+-----
t | 0/3003128 | 0/3003128 | t | 214
(1 row)
如果您在未同步的从站上运行此查询，结果将如下所示：
is_slave | receive | replay | synced | lag
----------+-----------+-----------+--------+-----
t | 0/30030F0 | 0/30023B0 | f | 129
(1 row)
注意：lag（秒）在这里有特殊含义（与pg_stat_replication 视图中的replay_lag/write_lag/flush_lag 不同）并且它仅在@ 时有用987654331@ 列是false，因为lag 表示自上次提交操作以来经过了多少秒。在低流量站点中，此值是无用的。但是在高流量站点中，synced 可能（并且将会）几乎是时间 false，但是如果它的 lag 值足够小，则可以认为服务器已同步。
因此，为了发现该服务器是否已同步，我检查（按此顺序）：
is_slave 是f（意思是不是slave，可能是master，所以是同步的）；synced 是t（意思是同步的slave，所以是同步的）；lag <= :threshold:（意思是不是同步的slave，但离master不是太远，所以对我来说已经足够同步了）。如果您想以秒为单位（包括小数），请执行以下操作：
SELECT
pg_is_in_recovery() AS is_slave,
pg_last_wal_receive_lsn() AS receive,
pg_last_wal_replay_lsn() AS replay,
pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() AS synced,
EXTRACT(SECONDS FROM now() - pg_last_xact_replay_timestamp())::float AS lag;
【讨论】：
主人，你可以做select * from pg_stat_replication;
这会给你：
| sent_lsn | write_lsn | flush_lsn | replay_lsn
-+-------------+-------------+-------------+-------------
| 8D/2DA48000 | 8D/2DA48000 | 8D/2DA48000 | 89/56A0D500
那些可以告诉你你的偏移量在哪里。 从这个例子可以看出，replay on the replica 落后了。
【讨论】：
您可以使用这个简单的基于 CLI 的开源工具，该工具可以使用各种模式提供有关复制延迟的实时可视化，例如CLI、Web 模式以及基于 matplotlib 的图表，便于跟踪。
随时提出任何问题或贡献。
【讨论】：