作者：汉斯·尤尔根·舍尔希(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：WAL Sender信息
人们经常说 pg_stat_replication视图是primary端的，这是不对的。该视图的作用是揭示有关wal sender进程的信息。换句话说：如果你正在运行级联复制，该视图意味着在secondary复制到其他slaves的时候， secondary端的 pg_stat_replication上的也会显示entries(条目)，以下图来说明该场景：
对于每个WAL Sender进程，你将精确获得一个entry(条目)，重要的是每个server只能看到复制链中的下一个server--一个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将会被持久化在slave上，但是只有当冲突被解决之后，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官方问答社区：www.pgfans.cn
下载更多PostgreSQL相关资料、工具、插件问题，请访问中国PostgreSQL官方下载网站：www.postgreshub.cn