使用 PG_STAT_REPLICATION 监视复制

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