pgsql之pg_stat_replication的使用詳解
pg_stat_replication是一個視圖,主要用於監控一個基於流的設置,建議您 註意系統上稱作pg_stat_replication的視圖。(註:當前版本為pg 10.0,10.0以下版本,字段名會有差異)此視圖包含以下信息:
\d pg_stat_replication
每個字段代碼的含義:
• pid
這代表負責流連接的wal_sender進程的進程ID。如果您在您的操作系統上檢查您進程表,您應該會找到一個帶有那個號碼的PostgreSQL進程。
• usesysid
每個內部用戶都有一個獨一無二的編號。該系統的工作原理很像UNIX。 usesysid 是 (PostgreSQL) 用戶連接到系統的唯一標識符。
• usename
(不是用戶名, 註意少瞭 r)它存儲與用戶相關的 usesysid 的名字。這是客戶端放入到連接字符串中的東西。
• application_name
這是同步復制的通常設置。它可以通過連接字符串傳遞到master。
• client_addr
它會告訴您流連接從何而來。它擁有客戶端的IP地址。
• client_hostname
除瞭客戶端的IP,您還可以這樣做,通過它的主機名來標識客戶端。您可以通過master上的postgresql.conf中的log_hostname啟用DNS反向查找。
• client_port
這是客戶端用來和WALsender進行通信使用的TPC端口號。 如果不本地UNIX套接字被使用瞭將顯示-1。
• backend_start
它告訴我們slave什麼時間創建瞭流連接。
• state
此列告訴我們數據的連接狀態。如果事情按計劃進行,它應該包含流信息。
• sent_lsn
這代表發送到連接的最後的事務日志的位置。
• write_lsn
這是寫到standby系統磁盤上最後的事務日志位置。
• flush_lsn
這是被刷新到standby系統的最後位置。(這裡註意寫和刷新之間的區別。寫並不意味著刷新 。)
• replay_lsn
這是slave上重放的最後的事務日志位置。
• sync_priority
這個字段是唯一和同步復制相關的。每次同步復制將會選擇一個優先權 —sync_priority—會告訴您選擇瞭那個優先權。
• sync_state
最後您會看到slave在哪個狀態。這個狀態可以是
async, sync, or potential。當有一個帶有較高優先權的同步slave時,PostgreSQL會把slave 標記為 potential。
在這個系統視圖中每個記錄隻代表一個slave。因此,可以看到誰處於連接狀態,在做什麼任務。pg_stat_replication也是檢查slave是否處於連接狀態的一個好方法。
上面說到pid代表負責流連接的wal_sender進程的進程ID,我們在機器上通過ps命令查看該進程的狀態:
ps -aux|grep 8225
在Linux上我們可以看到那個進程不僅有自己的作用 (在這種情況下, wal_sender),而且還帶有終端用戶的名字以及相關的網絡連接信息。在上圖中我們可以看到已經有人從192.168.47.127(對應pg_stat_replication的client_addr字段)通過51519(對應pg_stat_replication的client_port字段))端口連接到瞭master。
bonus:
上面我們提到replay_lsn
是slave上重放的最後的事務日志位置。
pg_current_wal_lsn()函數的作用是獲取當前的wal log的寫位置。
pg_wal_lsn_diff()函數的作用是計算兩個wal日志之間的差距。
所以我們可以通過下面的方法獲取高可用架構下從庫的復制延遲情況:
SELECT pg_wal_lsn_diff(A .c1, replay_lsn) /(1024 * 1024) AS slave_latency_MB FROM pg_stat_replication, pg_current_wal_lsn() AS A(c1) WHERE client_addr='%s' and application_name = '%s' ORDER BY slave_latency_MB LIMIT 1;
補充:PostgreSQL pg_stat_replication sync_state introduce
PostgreSQL 9.2引入同步復制後, pg_stat_replication的sync_state列有3種狀態.
sync
async
potential
分別代表同步standby, 異步standby, 可升級為同步的standby.
狀態來自以下函數 : pg_stat_get_wal_senders
[測試]
環境:
1個 primary, 3個 standby.
第一種配置 :
primary配置
postgresql.conf synchronous_standby_names = 'test1,test2,test3'
standby1配置
primary_conninfo = 'application_name=test1 host=127.0.0.1 port=1999 user=postgres keepalives_idle=60'
standby2配置
primary_conninfo = 'application_name=test2 host=127.0.0.1 port=1999 user=postgres keepalives_idle=60'
standby3配置
primary_conninfo = 'application_name=test3 host=127.0.0.1 port=1999 user=postgres keepalives_idle=60'
primary查詢
digoal=# select pid,application_name,client_addr,sync_state from pg_stat_replication; pid | application_name | client_addr | sync_state ------+------------------+-------------+------------ 6311 | test1 | 127.0.0.1 | sync 6321 | test2 | 127.0.0.1 | potential 6391 | test3 | 127.0.0.1 | potential (3 rows)
如果sync節點掛掉, 按synchronous_standby_names的順序, 第一個potential節點會變成sync狀態.
pg_ctl stop -m fast -D /pgdata11999 digoal=# select pid,application_name,client_addr,sync_state from pg_stat_replication; pid | application_name | client_addr | sync_state ------+------------------+-------------+------------ 6564 | test2 | 127.0.0.1 | sync 6568 | test3 | 127.0.0.1 | potential (2 rows)
當test1重新起來後又會變成sync狀態.
pg93@db-172-16-3-33-> pg_ctl start -D /pgdata11999 server starting digoal=# select pid,application_name,client_addr,sync_state from pg_stat_replication; pid | application_name | client_addr | sync_state ------+------------------+-------------+------------ 6564 | test2 | 127.0.0.1 | potential 6605 | test1 | 127.0.0.1 | sync 6568 | test3 | 127.0.0.1 | potential (3 rows)
第二種配置 :
primary配置
synchronous_standby_names = 'test1,test2'
standby1配置不變
standby2配置不變
standby3配置不變
primary查詢
digoal=# select pid,application_name,client_addr,sync_state from pg_stat_replication; pid | application_name | client_addr | sync_state ------+------------------+-------------+------------ 6470 | test1 | 127.0.0.1 | sync 6472 | test3 | 127.0.0.1 | async 6474 | test2 | 127.0.0.1 | potential (3 rows)
test3變成異步瞭. 因為test3沒有配置在primary的synchronous_standby_names 中.
第三種配置 :
primary配置
synchronous_standby_names = ‘test1’
standby1配置不變
standby2配置不變
standby3配置不變
primary查詢
digoal=# select pid,application_name,client_addr,sync_state from pg_stat_replication; pid | application_name | client_addr | sync_state ------+------------------+-------------+------------ 6519 | test2 | 127.0.0.1 | async 6521 | test3 | 127.0.0.1 | async 6523 | test1 | 127.0.0.1 | sync (3 rows)
test2,test3變成異步瞭. 因為test2,test3沒有配置在primary的synchronous_standby_names 中.
1. src/backend/replication/walsender.c
/* * Returns activity of walsenders, including pids and xlog locations sent to * standby servers. */ Datum pg_stat_get_wal_senders(PG_FUNCTION_ARGS) { ...略 /* * More easily understood version of standby state. This is purely * informational, not different from priority. */ if (sync_priority[i] == 0) values[7] = CStringGetTextDatum("async"); else if (i == sync_standby) values[7] = CStringGetTextDatum("sync"); else values[7] = CStringGetTextDatum("potential"); ...略
以上為個人經驗,希望能給大傢一個參考,也希望大傢多多支持WalkonNet。如有錯誤或未考慮完全的地方,望不吝賜教。
推薦閱讀:
- PostgreSQL 流復制異步轉同步的操作
- PostgreSQL12同步流復制搭建及主備切換方式
- postgresql13主從搭建Ubuntu
- CentOS PostgreSQL 12 主從復制(主從切換)操作
- postgresql 12版本搭建及主備部署操作