github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-26 16:46:28 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

README.md: improve documentation of repl_status view

Browse Source
This commit is contained in:
Ian Barwick
2016-05-16 13:51:08 +09:00
parent e814c1120e
commit 209de699ce
1 changed files with 9 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
README.md
View File

@@ -1016,8 +1016,11 @@ Monitoring
---------- ----------
When `repmgrd` is running with the option `-m/--monitoring-history`, it will When `repmgrd` is running with the option `-m/--monitoring-history`, it will
constantly write node status information to the `repl_monitor` table, which can constantly write standby node status information to the `repl_monitor` table,
be queried easily using the view `repl_status`: providing a near-real time overview of replication status on all nodes
in the cluster.
The view `repl_status` shows the most recent state for each node, e.g.:
repmgr=# SELECT * FROM repmgr_test.repl_status; repmgr=# SELECT * FROM repmgr_test.repl_status;
-[ RECORD 1 ]-------------+----------------------------- -[ RECORD 1 ]-------------+-----------------------------
@@ -1042,6 +1045,10 @@ table , it's advisable to regularly purge historical data with
`repmgr cluster cleanup`; use the `-k/--keep-history` to specify how `repmgr cluster cleanup`; use the `-k/--keep-history` to specify how
many day's worth of data should be retained. many day's worth of data should be retained.
Note that when a standby node is not streaming directly from its upstream
node, i.e. recovering WAL from an archive, `apply_lag` will always
appear as `0 bytes`.
Using a witness server with repmgrd Using a witness server with repmgrd
------------------------------------ ------------------------------------