PostgreSQL 复制（同步和异步复制）是数据库社区中最广泛使用的功能之一。如今，人们正在构建高可用性集群或使用复制来创建只读
副本来分散工作负载。这里需要注意的是，如果您使用复制，则必须确保您的集群受到正确监控。
这篇文章的目的是解释一些基础知识，以确保您的 PostgreSQL 集群保持健康。
pg_stat_replication：检查当前状态
监控复制的最佳方法是使用 pg_stat_replication，它包含很多重要信息。视图如下所示：
test=# \d pg_stat_replication
View "pg_catalog.pg_stat_replication"
Column | Type | Collation | Nullable | Default
-----------------+-------------------------+-----------+----------+---------
pid | integer | | |
usesysid | oid | | |
usename | name | | |
application_name | text | | |
client_addr | inet | | |
client_hostname | text | | |
client_port | integer | | |
backend_start | timestamp with time zone| | |
backend_xmin | xid | | |
state | text | | |
sent_lsn | pg_lsn | | |
write_lsn | pg_lsn | | |
flush_lsn | pg_lsn | | |
replay_lsn | pg_lsn | | |
write_lag | interval | | |
flush_lag | interval | | |
replay_lag | interval | | |
sync_priority | integer | | |
sync_state | text | | |
reply_time | timestamp with time zone| | |
多年来，此视图中的列数大幅增加。不过，我们首先讨论一些基本原理。
pg_stat_replication：WAL sender信息
人们常说 pg_stat_replication 位于“primary”上。这不完全正确。该视图的作用是公开有关 wal_sender 进程的信息。换句话说:如
果你正在运行级联复制，这意味着当一个从服务器复制到其他从服务器时，它可能也会显示条目。这是一张说明情况的图片：
对于每个 WAL sender进程，您将得到一个条目。重要的是，每个服务器只能看到链中的下一个服务器——发送服务器永远不会“看穿”从服务器。换句话说：在级联复制的情况下，您必须要求每个发送服务器获取概览。
还有更多：人们通常必须确定备库是否是最新的。这里有很多相关的事情：
- sent_lsn：已经通过网络发送了多少 WAL？
- write_lsn：已向操作系统发送了多少 WAL？（未刷盘）
- lush_lsn：有多少 WAL 已刷新到磁盘？
- replay_lsn：已经重播了多少 WAL，因此对查询可见？
下图说明了这些字段：
这里需要注意的是，PostgreSQL 提供了一种特殊的数据类型来表示这些数据：pg_lsn
可以轻松地找出当前的 WAL 位置。下面是它的工作原理：
test=# SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
3/DA06D240
(1 row)
这里值得注意的是可以进行计算：
test=# SELECT pg_current_wal_lsn() - '3/B549A845'::pg_lsn;
?column?
-----------
616376827
(1 row)
PostgreSQL 提供了各种运算符来执行此类计算。换句话说：很容易找出备库落后了多远。
flush_lsn 与 replay_lsn
人们一直在问我们flush_lsn 和 replay_lsn之间有什么区别。好吧，让我们深入研究一下:当WAL从主节点流向从节点时，它首先通过
网络发送，然后发送到操作系统，最后将事务刷新到磁盘，以确保持久性(=崩溃安全)。flush_lsn 显然表示最后一次刷写到磁盘的WAL
位置。现在的问题是：数据刷新后是否可见？答案是不，可能会有复制冲突。在发生复制冲突的情况下，WAL会持久化在备库上，只有
在冲突解决后才会重放。换句话说，可能发生的情况是，数据存储在从服务器上，但尚未重放使得用户最终可以访问。
注意这一点很重要，因为复制冲突发生的频率可能比您想象的要高。如果您看到如下消息，则说明您遇到了复制冲突：
ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
复制滞后
有时需要确定复制延迟量（以秒为单位）。到目前为止，我们已经看到了两个服务器之间的距离（以字节为单位）。如果您想测量滞后，
可以查看 _lag 列。这些列的数据类型是“间隔”，因此您可以看到延迟是多少秒甚至几分钟。如果复制工作正常，延迟通常非常非常小
（毫秒）。但是，您可能想要监视它。
需要注意的是：如果您正在运行大规模导入，例如 VACUUM 或其他一些昂贵的操作，很容易发生磁盘吞吐量高于网络带宽的情况。在这
种情况下，备库很有可能落后。您必须容忍这种情况，并确保警报不会过早启动。
pgwatch2：现成的工具
要监视复制，您可以依赖我刚才展示的手动魔术。然而，也有很多现成的工具来促进这项任务。我们可以推荐pgwatch2，它可以作为一
个容器免费下载。
