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

Update README

Browse Source
This commit is contained in:
Ian Barwick
2017-08-24 16:09:13 +09:00
parent 4f86fd681c
commit 8a8982d7d9
1 changed files with 13 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
README.md
View File

@@ -117,13 +117,11 @@ tables:
replication cluster replication cluster
- `repmgr.monitoring_history`: historical standby monitoring information written by `repmgrd` - `repmgr.monitoring_history`: historical standby monitoring information written by `repmgrd`
views: views:
- `repmgr.show_nodes`: based on the table `repl_nodes`, additionally showing the - `repmgr.show_nodes`: based on the table `repl_nodes`, additionally showing the
name of the server's upstream node name of the server's upstream node
- `repmgr.status`: when `repmgrd`'s monitoring is enabled, shows current monitoring - `repmgr.replication_status`: when `repmgrd`'s monitoring is enabled, shows current monitoring
status for each node status for each standby.
XXX not yet implemented
The `repmgr` metadata schema can be stored in an existing database or in its own The `repmgr` metadata schema can be stored in an existing database or in its own
dedicated database. Note that the `repmgr` metadata schema cannot reside on a database dedicated database. Note that the `repmgr` metadata schema cannot reside on a database
@@ -366,8 +364,18 @@ Note that when a standby node is not streaming directly from its upstream
node, e.g. recovering WAL from an archive, `apply_lag` will always appear as node, e.g. recovering WAL from an archive, `apply_lag` will always appear as
`0 bytes`. `0 bytes`.
XXX ALTER TABLE monitoring_history SET UNLOGGED ; * * *
> *TIP*: if monitoring history is enabled, the contents of the `monitoring_history`
> table will be replicated to attached standbys. This means there will be a small but
> constant stream of replication activity which may not be desirable. To prevent
> this, convert the table to an `UNLOGGED` one with:
>
> ALTER TABLE repmgr.monitoring_history SET UNLOGGED ;
>
> This will however mean that monitoring history will not be available on
> another node following a failover, and the view `replication_status`
> will not work on standbys.
Reference Reference