为了监控从一个 PostgreSQL 服务器到另一个 PostgreSQL 服务器的复制延迟,我使用了一个简单的脚本,它在主服务器上运行查询“SELECT pg_current_xlog_location()”,在从服务器上运行查询“SELECT pg_last_xlog_receive_location()”。然后我将结果从十六进制转换为十进制,并计算差值以获得复制延迟。
我的问题是我无法弄清楚这个 xlog_location 是以什么单位返回的。有人可以解释一下吗?
答案1
“单位不重要”(但如果你好奇的话,单位是事务日志中的位置——有一些讨论这里)。
值得注意的是不日志位置和时间之间存在正相关性。
大事务可能会在短时间内将日志向前移动很多。
使用率较低的数据库可能会停留在同一日志点数小时(或更长时间)。
通过这个测量你可以知道你在日志中落后了多少(即你是否与主服务器同步,以及大约需要发送/重放多少数据)。
还有更多讨论Postgres Wiki 中,但根据你的问题,我认为你已经读过这个页面了 - 在 Postgres 上提问可能是值得的pgsql-admin 邮件列表以便澄清(并且您可能会找到比我给您的更好的答案,并且也许能够更新 Postgres Wiki :-)
答案2
日志单位是字节(虽然它们是相对的 - 所以它们对于测量除了“偏移量”之外的任何东西都没有用,有时可能会出现“跳跃”,其中有很多跳过的字节),其值计算如下:
如果您采用 SELECT pg_current_xlog_location() 的输出,您将得到类似的结果:
70/A9002358
将“/”之前的部分乘以‘ff000000’并添加到第二部分:
用 Python 的说法(使用 int(‘HEX’,16) 函数将十六进制转换为)可能看起来像这样:
int('ff000000',16)*int('70',16) + int('A9002358',16)
您可以使用以下命令找到当前正在使用的 WAL 文件名:
select pg_xlogfile_name(pg_current_xlog_insert_location());
从技术上讲,如果从服务器需要的日志文件在主服务器上仍然可用,则从服务器“可能”赶上主服务器。当然,如果从服务器重放速度很慢,它可能永远赶不上主服务器 - 但您可以使用以下查询来衡量它是“赶上”还是“落后”(有点):
在从属设备上,你可以使用以下查询了解时间延迟:
SELECT extract(epoch from (now()-
pg_last_xact_replay_timestamp())) AS time_lag;
但是,返回的数字实际上是“自主服务器上次重放事务以来的时间” - 因此,如果主服务器有一段时间没有事务,那么“时间”可能会使从属服务器看起来像是落后了(而实际上,它已经赶上,但是主服务器上还没有事务。)