postgresql复制延迟

基础知识：复制和WAL

复制是一种机制，将来自一个数据库（“主”）的数据复制到另一个辅助数据库（“副本”或“备用数据库”），使其保持同步。 大多数数据库都具有支持此功能的内置机制。 为服务配置主PostgreSQL数据库后，应创建一个或多个副本数据库，以防丢失主数据库或决定从主数据库卸载某些操作。 通常，使用主数据库快照初始化副本，然后通过获取和重放主数据库事务来保持最新状态

PostgreSQL通过Write-Ahead-Log或“WAL”实现复制。 WAL的概念并不是PostgreSQL独有的，它类似于文件系统中的日记功能。它确保事务在提交之前被持久记录，因此可以在崩溃的情况下恢复和重放更新。除了崩溃恢复之外，PostgreSQL还利用WAL实现内部性能提升和内置复制支持。

WAL是位于数据目录的pg_xlog目录中的16MB二进制文件的集合。每次数据库获得需要更改任何数据的事务时，它会将事务记录附加到最近创建的WAL段文件，并为记录分配日志序列号（LSN）以记录其在WAL中的位置。我明确说明了位置而不是时间，因为正如日志序列号所暗示的那样，WAL文件及其各自的记录基于基于序列的时间轴。为什么？因为如果您正在处理大量事务，则时间戳可能不是唯一的或粒度足以验证您的事务是否以正确的顺序执行。稍后当我们查看可用于查找主要内容和副本在WAL中的位置的查询时，这将非常重要。

PostgreSQL使用WAL以两种方式之一制作主要副本。最新和最好的是通过流复制，其中每个WAL日志记录尽可能快地发送到副本以进行重放。默认情况下，这是异步完成的，因此副本可以处理记录而不会延迟主服务器上的提交;但是，PostgreSQL还支持同步复制，其中主要事务必须等到主记录和副本上都提交WAL记录，然后才能认为事务成功。

为什么关心滞后？

复制滞后是副本在顺序时间轴中主要位置之后的距离。 将数据从主数据库复制到副本服务器并应用更改所花费的时间可能因许多因素而异，包括网络时间，复制配置以及主数据库和副本服务器上的活动。 不出所料，由于网络问题，我曾多次看到复制延迟飙升。 在另一种情况下，我看到副本上的复制滞后峰值无法从归档节点中找到并恢复WAL文件，并且它悄然过时了。 潜在的原因很普遍，我发现复制滞后通常表明某些事情正在巧妙地失败或出现意外行为。

最终，可以安全地假设任何副本都会有一些延迟。 但为什么你需要知道集群中的复制滞后？

灾难恢复

在主数据库丢失的大多数情况下，用户希望提升最新的副本以确保最小的数据丢失。您和您的工具可以测量延迟，以选择主要的最佳替换。

服务策略和优化

如果将所有客户端连接到主服务器，最终将使数据库过载。当发生这种情况时，常见的技术是将一些只读查询引导到副本;但是，如果您不构建服务以了解并容忍复制延迟，那么您的用户将会遇到来自您的服务的不一致行为。了解副本的典型复制滞后将帮助您制定策略，尽管存在潜在的延迟，哪些服务仍可正常运行。

调试和观察

正如在HTTP请求中测量延迟可以指示潜在问题一样，异常高的复制滞后可能表明数据库存在问题。遗憾的是，孤立的复制滞后很少会告知用户特定的潜在问题，但它是几个问题的广泛指标，是您的可观察性工具带中的另一个数据点。

如何监控滞后：让你的“看到滞后”

现在我们已经掌握了监控复制滞后的重要性，让我们深入探讨两种测量复制滞后的方法。

按WAL位置

确定滞后的最准确方法是将主数据库上的当前WAL位置与备用数据库接收的最后一个WAL位置进行比较。 要在早于10.x的Postgres版本中查找当前WAL位置的LSN值，请在主服务器上运行以下命令：

#主上执行
postgres=# select pg_current_wal_lsn();
#9.x版本
postgres=# select pg_current_xlog_location();
 pg_current_xlog_location 
--------------------------
 110/9C8294B0
(1 row)

要查找备用数据库收到的最后一个WAL位置的LSN值并将其同步到磁盘，请在副本服务器上运行以下命令。

#从上执行
# Postgres 10.x
# select pg_last_wal_receive_lsn();
# Postgres 9.x
postgres=# select pg_last_xlog_receive_location();
 pg_last_xlog_receive_location 
-------------------------------
 110/9C8294B0
(1 row)

您可以通过比较副主机上已提交的内容以及副本上已接收或重播的内容的值来确定副本是否与WAL中的主副本位于主副本中。 使用WAL位置的缺点在于，尽管是滞后的准确表示，但人们很难理解LSN差异的真正含义。 我已经看到了将LSN转换为WAL中的字节位置的聪明脚本并获取这些值的差异，但是有一个更简单的选项可以利用另一个内置函数来估计时滞。

按时差

我之前告诉过你，WAL基于一个序列，但时间戳对人类更具可读性，并且可由外部工具比WAL位置值更容易吸收。 PostgreSQL可以提取给定WAL位置的时间戳，允许您使用副本上的以下查询将WAL中最后一次播放的事务的时间戳与当前时间进行比较：

#从上执行
# Same in both Postgres 9.x and 10.x 
postgres=# select now() - pg_last_xact_replay_timestamp();
    ?column?     
-----------------
 14:15:14.613954
(1 row)

需要使用额外的上下文读取此值。 它应该是滞后的近似值，应该这样对待。 我发现这个查询最有用的是注入我的时间序列可观察性度量标准，或者在运行可能影响滞后的操作时抛入终端窗格。 如果要选择副本来替换失败的主数据库，则应使用LSN而不是LSN的大致时间戳。

参考:http://sysadvent.blogspot.com/2017/12/day-12-monitoring-postgres-replication.html