作者：漢斯·尤爾根·舍爾希(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官方網站

解決更多PostgreSQL相關知識、技術、工作問題，請訪問中國PostgreSQL官方問答社區

下載更多PostgreSQL相關資料、工具、插件問題，請訪問中國PostgreSQL官方下載網站

總結

以上是生活随笔為你收集整理的使用PG_STAT_REPLICATION监视复制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。