作者：汉斯·尤尔根·舍尔希(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_replicationView "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