作者：汉斯
·
尤尔根
·
舍尔希(Hans-JürgenSchönig)，从上世纪90年代开始使用PostgreSQL，他是CYBERTEC公司的CEO与技术带头人，
CYBERTEC
是该领域的市场领导者之一，自2000年以来已为全球无数客户提供服务。他著有图书《Mastering PostgreSQL 9.6: A comprehensive guide for PostgreSQL 9.6 developers and administrators》和《Mastering PostgreSQL 11，Second Edition》，这两本英文图书均已经由武汉大学彭煜玮老师翻译完成并均已出版，中文书名分别为《由浅入深PostgreSQL》、《精通PostgreSQL 11第二版》
译者：
类延良，任职于瀚高基础软件股份有限公司，PostgreSQL数据库技术爱好者，10g &11g OCM，OGG认证专家。
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 ：W AL Sender 信息
人们经常说 pg_stat_replication 视图是p rimary 端的，这是不对的。该视图的作用是揭示有关w al sender 进程的信息。换句话说：如果你正在运行级联复制，该视图意味着在 secondary 复制到其他slaves 的时候， secondary 端的 pg_stat_replication 上的也会显示entries ( 条目 ) ，以下图来说明该场景：
对于每个WAL
Sender进程，你将精确获得一个entry
(
条目
)
，重要的是每个server只能看到复制链中的下一个serve
r--
一个sending
server
永远不会通过一个
slave
看到，
换句话说：在级联复制中，你不得不询问每个sending
server以获得复制的概况。
但是还有更多：人们通常必须确定
slave
是否最新。这里有很多相关的事情：
sent_lsn：已经通过网络发送了多少WAL？
write_lsn：已向操作系统发送了多少WAL？（ 尚未 flushing）
flush_lsn：已经有多少WAL已 flush 到磁盘？
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 从 primary 流向 slave 时， 它首先通过网络发送，然后发送到操作系统，最后将事务刷新到磁盘以确保持久性（即崩溃安全性） 。 flush_lsn 显然表示刷新到磁盘的最后一个 WAL 位置 。 现在的问题是：数据刷新后是否立即可见？答案是：不， 如我们的较早的博客文章中所述， 可能存在复制冲突 。如果发生复制冲突，则WAL 将 会被持久化 在 s lave 上 ，但是只有当冲突被解决之后，WAL 才会 replay 。换句话说，可能存在如下情况： data 被存储在 slave 上，但是没有被 replay 并被最终用户访问。
注意这一点很重要，因为复制冲突比您想象的要经常发生。如果您看到以下消息，则说明您遇到了复制冲突：
ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
Replication lags
有时有必要确定复制延迟的数量（以秒为单位） ， 到目前为止，我们已经看到了两个服务器之间的距离（以字节为单位） 。 如果要测量 lag ，可以查看pg_stat_replication 系统视图的相关 _lag 列 ( 译者注： write_lag 、 flush_lag 、 replay_lag) ， 这些列的数据类型为“interval” ， 因此您可以看到延迟的秒数或分钟数 ， 如果复制工作正常，则延迟通常会非常小（毫秒）。但是，您可能要监视它。
提 醒您：如果您正在运行 诸如 VACUUM 之类的大规模导入或其他昂贵的操作，则容易发生磁盘吞吐量可能会高于网络带宽。在这种情况下， slave 可能会落后。您必须忍受这一点，并确保警报不会过早开始。
pgwatch2: Ready made tooling
要监视复制，您可以依靠我刚刚显示的手动魔术 ( manual magic ) 。但是，那里也有很多现成的工具可以简化此任务。我们可以推荐pgwatch2 ，它可以作为容器免费下载。
如果您想查看演示pgwatch 如何工作的演示，请考虑查看我们的 pawatch2 网站 （ https://www.cybertec-postgresql.com/en/products/pgwatch/ ）
Finally …
如果您想全面了解PostgreSQL ，建议您阅读其他一些文章。如果您对存储感兴趣，则可能需要阅读我们 有关zheap 的 帖子之一
（ https://www.cybertec-postgresql.com/en/zheap-reinvented-postgresql-storage/ ） 原文链接： https://www.cybertec-postgresql.com/en/monitoring-replication-pg_stat_replication/ 了解更多PostgreSQL热点资讯、新闻动态、精彩活动，请访问中国PostgreSQL官方网站 ： www.postgresqlchina.com 解决更多PostgreSQL相关知识、技术、工作问题，请访问中国PostgreSQL官方问答社区： 下载更多PostgreSQL相关资料、工具、插件问题，请访问中国PostgreSQL官方下载网站： www.postgreshub.cn
