diff --git a/doc/repmgr-cluster-cleanup.sgml b/doc/repmgr-cluster-cleanup.sgml
index e945ef06..7ad310cc 100644
--- a/doc/repmgr-cluster-cleanup.sgml
+++ b/doc/repmgr-cluster-cleanup.sgml
@@ -1,23 +1,41 @@
-
+repmgr cluster cleanup
- repmgr cluster cleanup
-
- Purges monitoring history from the repmgr.monitoring_history table to
- prevent excessive table growth. Use the -k/--keep-history to specify the
- number of days of monitoring history to retain. This command can be used
- manually or as a cronjob.
-
-
- This command requires a valid repmgr.conf file for the node on which it is
- executed; no additional arguments are required.
-
-
-
- Monitoring history will only be written if repmgrd is active, and
- monitoring_history is set to true in
- repmgr.conf.
-
-
-
+
+ repmgr cluster cleanup
+
+
+
+ repmgr cluster cleanup
+ purge monitoring history
+
+
+
+ Description
+
+ Purges monitoring history from the repmgr.monitoring_history table to
+ prevent excessive table growth. Use the -k/--keep-history to specify the
+ number of days of monitoring history to retain. This command can be used
+ manually or as a cronjob.
+
+
+
+
+ Usage
+
+ This command requires a valid repmgr.conf file for the node on which it is
+ executed; no additional arguments are required.
+
+
+
+
+ Notes
+
+
+ Monitoring history will only be written if repmgrd is active, and
+ monitoring_history is set to true in
+ repmgr.conf.
+
+
+
diff --git a/doc/repmgr-cluster-crosscheck.sgml b/doc/repmgr-cluster-crosscheck.sgml
index dd361883..77c98bc7 100644
--- a/doc/repmgr-cluster-crosscheck.sgml
+++ b/doc/repmgr-cluster-crosscheck.sgml
@@ -1,15 +1,27 @@
-
+repmgr cluster crosscheck
- repmgr cluster crosscheck
-
- repmgr cluster crosscheck is similar to ,
- but cross-checks connections between each combination of nodes. In "Example 3" in
- we have no information about the state of node3.
- However by running repmgr cluster crosscheck it's possible to get a better
- overview of the cluster situation:
-
+
+
+
+ repmgr cluster crosscheck
+
+
+
+ repmgr cluster crosscheck
+ cross-checks connections between each combination of nodes
+
+
+
+ Description
+
+ repmgr cluster crosscheck is similar to ,
+ but cross-checks connections between each combination of nodes. In "Example 3" in
+ we have no information about the state of node3.
+ However by running repmgr cluster crosscheck it's possible to get a better
+ overview of the cluster situation:
+
$ repmgr -f /etc/repmgr.conf cluster crosscheck
Name | Id | 1 | 2 | 3
@@ -17,12 +29,14 @@
node1 | 1 | * | * | x
node2 | 2 | * | * | *
node3 | 3 | * | * | *
-
-
- What happened is that repmgr cluster crosscheck merged its own
- repmgr cluster matrix with the repmgr cluster matrix
- output from node2; the latter is able to connect to node3
- and therefore determine the state of outbound connections from that node.
-
-
+
+
+ What happened is that repmgr cluster crosscheck merged its own
+ repmgr cluster matrix with the
+ repmgr cluster matrix output from node2; the latter is
+ able to connect to node3
+ and therefore determine the state of outbound connections from that node.
+
+
+
diff --git a/doc/repmgr-cluster-event.sgml b/doc/repmgr-cluster-event.sgml
index f1f24fb7..d3f63ed1 100644
--- a/doc/repmgr-cluster-event.sgml
+++ b/doc/repmgr-cluster-event.sgml
@@ -1,37 +1,60 @@
-
-
- repmgr cluster event
-
- repmgr cluster event
-
- This outputs a formatted list of cluster events, as stored in the
- repmgr.events table. Output is in reverse chronological order, and
- can be filtered with the following options:
-
-
- --all: outputs all entries
-
-
- --limit: set the maximum number of entries to output (default: 20)
-
-
- --node-id: restrict entries to node with this ID
-
-
- --node-name: restrict entries to node with this name
-
-
- --event: filter specific event
-
-
-
-
- Example:
-
+
+
+ repmgr cluster event
+
+
+
+ repmgr cluster event
+
+
+
+ repmgr cluster event
+ output a formatted list of cluster events
+
+
+
+ Description
+
+
+ Outputs a formatted list of cluster events, as stored in the repmgr.events table.
+
+
+
+
+ Usage
+
+
+ Output is in reverse chronological order, and
+ can be filtered with the following options:
+
+
+ --all: outputs all entries
+
+
+ --limit: set the maximum number of entries to output (default: 20)
+
+
+ --node-id: restrict entries to node with this ID
+
+
+ --node-name: restrict entries to node with this name
+
+
+ --event: filter specific event
+
+
+
+
+
+
+ Example
+
+
$ repmgr -f /etc/repmgr.conf cluster event --event=standby_register
Node ID | Name | Event | OK | Timestamp | Details
---------+-------+------------------+----+---------------------+--------------------------------
3 | node3 | standby_register | t | 2017-08-17 10:28:55 | standby registration succeeded
2 | node2 | standby_register | t | 2017-08-17 10:28:53 | standby registration succeeded
-
-
+
+
+
diff --git a/doc/repmgr-cluster-matrix.sgml b/doc/repmgr-cluster-matrix.sgml
index 2f57060a..30c0b2a9 100644
--- a/doc/repmgr-cluster-matrix.sgml
+++ b/doc/repmgr-cluster-matrix.sgml
@@ -1,27 +1,44 @@
-
+repmgr cluster matrix
- repmgr cluster matrix
-
- repmgr cluster matrix runs repmgr cluster show on each
- node and arranges the results in a matrix, recording success or failure.
-
-
- repmgr cluster matrix requires a valid repmgr.conf
- file on each node. Additionally passwordless ssh connections are required between
- all nodes.
-
-
+
+
+ repmgr cluster matrix
+
+
+
+ repmgr cluster matrix
+
+ runs repmgr cluster show on each node and summarizes output
+
+
+
+
+ Description
+
+ repmgr cluster matrix runs repmgr cluster show on each
+ node and arranges the results in a matrix, recording success or failure.
+
+
+ repmgr cluster matrix requires a valid repmgr.conf
+ file on each node. Additionally, passwordless ssh connections are required between
+ all nodes.
+
+
+
+
+ Example
+
Example 1 (all nodes up):
$ repmgr -f /etc/repmgr.conf cluster matrix
Name | Id | 1 | 2 | 3
-------+----+----+----+----
- node1 | 1 | * | * | *
- node2 | 2 | * | * | *
- node3 | 3 | * | * | *
+ node1 | 1 | * | * | *
+ node2 | 2 | * | * | *
+ node3 | 3 | * | * | *
Example 2 (node1 and node2 up, node3 down):
@@ -79,5 +96,6 @@
In this case, the command will produce a more
useful result.
-
+
+
diff --git a/doc/repmgr-cluster-show.sgml b/doc/repmgr-cluster-show.sgml
index e902a0af..6616bbc5 100644
--- a/doc/repmgr-cluster-show.sgml
+++ b/doc/repmgr-cluster-show.sgml
@@ -1,21 +1,46 @@
-
+repmgr cluster show
- repmgr cluster show
-
- Displays information about each active node in the replication cluster. This
- command polls each registered server and shows its role (primary /
- standby / bdr) and status. It polls each server
- directly and can be run on any node in the cluster; this is also useful when analyzing
- connectivity from a particular node.
-
-
- This command requires either a valid repmgr.conf file or a database
- connection string to one of the registered nodes; no additional arguments are needed.
-
-
- Example:
+
+
+ repmgr cluster show
+
+
+
+ repmgr cluster show
+ display information about each registered node in the replication cluster
+
+
+
+
+ Description
+
+ Displays information about each registered node in the replication cluster. This
+ command polls each registered server and shows its role (primary /
+ standby / bdr) and status. It polls each server
+ directly and can be run on any node in the cluster; this is also useful when analyzing
+ connectivity from a particular node.
+
+
+
+
+ Execution
+
+ This command requires either a valid repmgr.conf file or a database
+ connection string to one of the registered nodes; no additional arguments are needed.
+
+
+
+ To show database connection errors when polling nodes, run the command in
+ --verbose mode.
+
+
+
+
+
+ Example
+
$ repmgr -f /etc/repmgr.conf cluster show
@@ -25,18 +50,15 @@
2 | node2 | standby | running | node1 | default | host=db_node2 dbname=repmgr user=repmgr
3 | node3 | standby | running | node1 | default | host=db_node3 dbname=repmgr user=repmgr
-
-
- To show database connection errors when polling nodes, run the command in
- --verbose mode.
-
-
-
- Note that the column Role shows the expected server role according to the
- &repmgr; metadata. Status shows whether the server is running or unreachable.
- If the node has an unexpected role not reflected in the &repmgr; metadata, e.g. a node was manually
- promoted to primary, this will be highlighted with an exclamation mark, e.g.:
-
+
+
+ Notes
+
+ The column Role shows the expected server role according to the
+ &repmgr; metadata. Status shows whether the server is running or unreachable.
+ If the node has an unexpected role not reflected in the &repmgr; metadata, e.g. a node was manually
+ promoted to primary, this will be highlighted with an exclamation mark, e.g.:
+
$ repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
@@ -48,43 +70,47 @@
WARNING: following issues were detected
node "node1" (ID: 1) is registered as an active primary but is unreachable
node "node2" (ID: 2) is registered as standby but running as primary
-
+
+
+ Node availability is tested by connecting from the node where
+ repmgr cluster show is executed, and does not necessarily imply the node
+ is down. See and to get
+ a better overviews of connections between nodes.
+
+
-
- repmgr cluster show accepts an optional parameter --csv, which
- outputs the replication cluster's status in a simple CSV format, suitable for
- parsing by scripts:
-
+
+ Options
+
+ repmgr cluster show accepts an optional parameter --csv, which
+ outputs the replication cluster's status in a simple CSV format, suitable for
+ parsing by scripts:
+
$ repmgr -f /etc/repmgr.conf cluster show --csv
1,-1,-1
2,0,0
3,0,1
-
-
- The columns have following meanings:
-
-
-
- node ID
-
-
-
-
- availability (0 = available, -1 = unavailable)
-
-
-
-
- recovery state (0 = not in recovery, 1 = in recovery, -1 = unknown)
-
-
-
-
+
+
+ The columns have following meanings:
+
+
+
+ node ID
+
+
+
+
+ availability (0 = available, -1 = unavailable)
+
+
+
+
+ recovery state (0 = not in recovery, 1 = in recovery, -1 = unknown)
+
+
+
+
+
-
- Note that the availability is tested by connecting from the node where
- repmgr cluster show is executed, and does not necessarily imply the node
- is down. See and to get
- a better overviews of connections between nodes.
-
-
+
diff --git a/doc/repmgr-node-check.sgml b/doc/repmgr-node-check.sgml
index b9a5b5f2..46a2de80 100644
--- a/doc/repmgr-node-check.sgml
+++ b/doc/repmgr-node-check.sgml
@@ -1,32 +1,48 @@
-
+repmgr node check
- repmgr node check
-
- Performs some health checks on a node from a replication perspective.
- This command must be run on the local node.
-
-
- Sample output (execute repmgr node check):
-
+
+
+ repmgr node check
+
+
+
+ repmgr node check
+ performs some health checks on a node from a replication perspective
+
+
+
+ Description
+
+ Performs some health checks on a node from a replication perspective.
+ This command must be run on the local node.
+
+
+
+
+ Example
+
+
+ $ repmgr -f /etc/repmgr.conf node check
Node "node1":
Server role: OK (node is primary)
Replication lag: OK (N/A - node is primary)
WAL archiving: OK (0 pending files)
Downstream servers: OK (2 of 2 downstream nodes attached)
- Replication slots: OK (node has no replication slots)
-
-
-
- Additionally each check can be performed individually by supplying
- an additional command line parameter, e.g.:
-
- $ repmgr node check --role
- OK (node is primary)
-
-
-
+ Replication slots: OK (node has no replication slots)
+
+
+
+ Individual checks
+
+ Each check can be performed individually by supplying
+ an additional command line parameter, e.g.:
+
+ $ repmgr node check --role
+ OK (node is primary)
+
+
Parameters for individual checks are as follows:
@@ -67,4 +83,5 @@
Individual checks can also be output in a Nagios-compatible format by additionally
providing the option --nagios.
-
+
+
diff --git a/doc/repmgr-node-rejoin.sgml b/doc/repmgr-node-rejoin.sgml
index 4704e024..55cb0bd2 100644
--- a/doc/repmgr-node-rejoin.sgml
+++ b/doc/repmgr-node-rejoin.sgml
@@ -1,58 +1,75 @@
-
+repmgr node rejoin
- repmgr node rejoin
-
- Enables a dormant (stopped) node to be rejoined to the replication cluster.
-
-
-
- Currently repmgr node rejoin can only be used to attach
- a standby to the current primary, not another standby.
-
-
+
+ repmgr node rejoin
+
-
+
+ repmgr node rejoin
+ rejoin a dormant (stopped) node to the replication cluster
+
+
+
+ Description
- If the node is running and needs to be attached to the current primary, use
- .
+ Enables a dormant (stopped) node to be rejoined to the replication cluster.
-
-
-
- This can optionally use pg_rewind to re-integrate a node which has diverged
- from the rest of the cluster, typically a failed primary.
-
-
- The node must have been shut down cleanly; if this was not the case, it will
- need to be manually started (remove any existing recovery.conf file first)
- until it has reached a consistent recovery point, then shut down cleanly.
-
-
- If PostgreSQL is started in single-user mode and
- input is directed from /dev/null/, it will perform recovery
- then immediately quit, and will then be in a state suitable for use by
- pg_rewind.
+ This can optionally use pg_rewind to re-integrate
+ a node which has diverged from the rest of the cluster, typically a failed primary.
+
+
+
+
+ If the node is running and needs to be attached to the current primary, use
+ .
+
+
+
+
+
+
+ Usage
+
+
- rm -f /var/lib/pgsql/data/recovery.conf
- postgres --single -D /var/lib/pgsql/data/ < /dev/null
-
-
-
- Usage:
-
repmgr node rejoin -d '$conninfo'
- where $conninfo is the conninfo string of any reachable node in the cluster.
- repmgr.conf for the stopped node *must* be supplied explicitly if not
- otherwise available.
-
+ where $conninfo is the conninfo string of any reachable node in the cluster.
+ repmgr.conf for the stopped node *must* be supplied explicitly if not
+ otherwise available.
+
+
-
+
+ Notes
+
+ Currently repmgr node rejoin can only be used to attach
+ a standby to the current primary, not another standby.
+
+
+ The node must have been shut down cleanly; if this was not the case, it will
+ need to be manually started (remove any existing recovery.conf file first)
+ until it has reached a consistent recovery point, then shut down cleanly.
+
+
+
+ If PostgreSQL is started in single-user mode and
+ input is directed from /dev/null/, it will perform recovery
+ then immediately quit, and will then be in a state suitable for use by
+ pg_rewind.
+
+ rm -f /var/lib/pgsql/data/recovery.conf
+ postgres --single -D /var/lib/pgsql/data/ < /dev/null
+
+
+
+
+ Using <command>pg_rewind</command>repmgr node rejoin can optionally use pg_rewind to re-integrate a
@@ -118,5 +135,14 @@
NOTICE: NODE REJOIN successful
DETAIL: node 1 is now attached to node 2
-
-
+
+
+
+
+
+ See also
+
+
+
+
+
diff --git a/doc/repmgr-node-status.sgml b/doc/repmgr-node-status.sgml
index 8789b1ca..e44d29b3 100644
--- a/doc/repmgr-node-status.sgml
+++ b/doc/repmgr-node-status.sgml
@@ -1,16 +1,30 @@
-
-
+repmgr node status
- repmgr node status
-
- Displays an overview of a node's basic information and replication
- status. This command must be run on the local node.
-
-
- Sample output (execute repmgr node status):
-
+
+
+ repmgr node status
+
+
+
+ repmgr node status
+ show overview of a node's basic information and replication status
+
+
+
+ Description
+
+ Displays an overview of a node's basic information and replication
+ status. This command must be run on the local node.
+
+
+
+
+ Example
+
+
+ $ repmgr -f /etc/repmgr.comf node status
Node "node1":
PostgreSQL version: 10beta1
Total data size: 30 MB
@@ -20,10 +34,14 @@
Archive command: (none)
Replication connections: 2 (of maximal 10)
Replication slots: 0 (of maximal 10)
- Replication lag: n/a
-
-
-
- See to diagnose issues.
-
-
+ Replication lag: n/a
+
+
+
+
+ See also
+
+ See to diagnose issues.
+
+
+
diff --git a/doc/repmgr-primary-register.sgml b/doc/repmgr-primary-register.sgml
index 34f78725..7300f6b0 100644
--- a/doc/repmgr-primary-register.sgml
+++ b/doc/repmgr-primary-register.sgml
@@ -1,32 +1,51 @@
-
- repmgr primary register
- repmgr primary register
-
- repmgr primary register registers a primary node in a
- streaming replication cluster, and configures it for use with repmgr, including
- installing the &repmgr; extension. This command needs to be executed before any
- standby nodes are registered.
-
-
- Execute with the --dry-run option to check what would happen without
- actually registering the primary.
-
-
- repmgr master register can be used as an alias for
- repmgr primary register.
-
+
+
+ repmgr primary register
+
-
+
+ repmgr primary register
+
+
+
+ repmgr primary register
+ initialise a repmgr installation and register the primary node
+
+
+
+
+ Description
+
+ repmgr primary register registers a primary node in a
+ streaming replication cluster, and configures it for use with repmgr, including
+ installing the &repmgr; extension. This command needs to be executed before any
+ standby nodes are registered.
+
+
+
+
+ Execution
+
+ Execute with the --dry-run option to check what would happen without
+ actually registering the primary.
+
+
+ repmgr master register can be used as an alias for
+ repmgr primary register.
+
+
+
If providing the configuration file location with -f/--config-file,
avoid using a relative path, as &repmgr; stores the configuration file location
in the repmgr metadata for use when &repmgr; is executed remotely (e.g. during
). &repmgr; will attempt to convert the
- a relative path into an absolute one, but this may not be the same as the path you
- would explicitly provide (e.g. ./repmgr.conf might be converted
- to /path/to/./repmgr.conf, whereas you'd normally write
- /path/to/repmgr.conf).
+ a relative path into an absolute one, but this may not be the same as the path you
+ would explicitly provide (e.g. ./repmgr.conf might be converted
+ to /path/to/./repmgr.conf, whereas you'd normally write
+ /path/to/repmgr.conf).
-
+
+
-
+
diff --git a/doc/repmgr-primary-unregister.sgml b/doc/repmgr-primary-unregister.sgml
index c09d05cb..ab001cbc 100644
--- a/doc/repmgr-primary-unregister.sgml
+++ b/doc/repmgr-primary-unregister.sgml
@@ -1,18 +1,34 @@
-
- repmgr primary unregister
- repmgr primary unregister
-
- repmgr primary register unregisters an inactive primary node
- from the &repmgr; metadata. This is typically when the primary has failed and is
- being removed from the cluster after a new primary has been promoted.
-
-
- Execute with the --dry-run option to check what would happen without
- actually unregistering the node.
-
+
+
+ repmgr primary unregister
+
+
+ repmgr primary unregister
+
+
+ repmgr primary unregister
+ unregister an inactive primary node
+
-
- repmgr master unregister can be used as an alias for
- repmgr primary unregister/
-
-
+
+ Description
+
+ repmgr primary register unregisters an inactive primary node
+ from the &repmgr; metadata. This is typically when the primary has failed and is
+ being removed from the cluster after a new primary has been promoted.
+
+
+
+
+ Execution
+
+ Execute with the --dry-run option to check what would happen without
+ actually unregistering the node.
+
+
+
+ repmgr master unregister can be used as an alias for
+ repmgr primary unregister/
+
+
+
diff --git a/doc/repmgr-standby-clone.sgml b/doc/repmgr-standby-clone.sgml
index 1908f285..fbc6879f 100644
--- a/doc/repmgr-standby-clone.sgml
+++ b/doc/repmgr-standby-clone.sgml
@@ -1,25 +1,37 @@
-
+repmgr standby clonecloning
- repmgr standby clone
-
- repmgr standby clone clones a PostgreSQL node from another
- PostgreSQL node, typically the primary, but optionally from any other node in
- the cluster or from Barman. It creates the recovery.conf file required
- to attach the cloned node to the primary node (or another standby, if cascading replication
- is in use).
-
-
-
- repmgr standby clone does not start the standby, and after cloning
- repmgr standby register must be executed to notify &repmgr; of its presence.
-
-
+
+
+ repmgr standby clone
+
+
+
+ repmgr standby clone
+ clone a PostgreSQL standby node from another PostgreSQL node
+
+
+
+ Description
+
+ repmgr standby clone clones a PostgreSQL node from another
+ PostgreSQL node, typically the primary, but optionally from any other node in
+ the cluster or from Barman. It creates the recovery.conf file required
+ to attach the cloned node to the primary node (or another standby, if cascading replication
+ is in use).
+
+
+
+ repmgr standby clone does not start the standby, and after cloning
+ repmgr standby register must be executed to notify &repmgr; of its presence.
+
+
+
-
+ Handling configuration files
@@ -51,9 +63,9 @@
configuration management tool such as Ansible, Chef, Puppet or Salt.
-
+
-
+ Managing WAL during the cloning process
When initially cloning a standby, you will need to ensure
@@ -86,6 +98,6 @@
--wal-method.
-
-
+
+
diff --git a/doc/repmgr-standby-follow.sgml b/doc/repmgr-standby-follow.sgml
index f928dcaf..adb328b1 100644
--- a/doc/repmgr-standby-follow.sgml
+++ b/doc/repmgr-standby-follow.sgml
@@ -1,26 +1,41 @@
-
+repmgr standby follow
- repmgr standby follow
-
- Attaches the standby to a new primary. This command requires a valid
- repmgr.conf file for the standby, either specified
- explicitly with -f/--config-file or located in a
- default location; no additional arguments are required.
-
-
- This command will force a restart of the standby server, which must be
- running. It can only be used to attach an active standby to the current primary node
+
+
+ repmgr standby follow
+
+
+
+ repmgr standby follow
+ attach a standby to a new primary
+
+
+
+ Description
+
+
+ Attaches the standby to a new primary. This command requires a valid
+ repmgr.conf file for the standby, either specified
+ explicitly with -f/--config-file or located in a
+ default location; no additional arguments are required.
+
+
+ This command will force a restart of the standby server, which must be
+ running. It can only be used to attach an active standby to the current primary node
(and not to another standby).
-
-
- To re-add an inactive node to the replication cluster, see
-
-
-
- Example execution:
-
+
+
+ To re-add an inactive node to the replication cluster, see
+
+
+
+
+
+ Example
+
+
$ repmgr -f /etc/repmgr.conf standby follow
INFO: setting node 3's primary to node 2
NOTICE: restarting server using "pg_ctl -l /var/log/postgres/startup.log -w -D '/var/lib/postgres/data' restart"
@@ -30,6 +45,14 @@
server started
NOTICE: STANDBY FOLLOW successful
DETAIL: node 3 is now attached to node 2
-
-
+
+
+
+
+ See also
+
+
+
+
+
diff --git a/doc/repmgr-standby-promote.sgml b/doc/repmgr-standby-promote.sgml
index 0709ae0a..898f9690 100644
--- a/doc/repmgr-standby-promote.sgml
+++ b/doc/repmgr-standby-promote.sgml
@@ -1,30 +1,44 @@
-
+repmgr standby promote
- repmgr standby promote
-
- Promotes a standby to a primary if the current primary has failed. This
- command requires a valid repmgr.conf file for the standby, either
- specified explicitly with -f/--config-file or located in a
- default location; no additional arguments are required.
-
-
- If the standby promotion succeeds, the server will not need to be
- restarted. However any other standbys will need to follow the new server,
- by using ; if repmgrd
- is active, it will handle this automatically.
-
-
- Example execution:
-
+
+
+ repmgr standby promote
+
+
+
+ repmgr standby promote
+ promote a standby to a primary
+
+
+
+ Description
+
+ Promotes a standby to a primary if the current primary has failed. This
+ command requires a valid repmgr.conf file for the standby, either
+ specified explicitly with -f/--config-file or located in a
+ default location; no additional arguments are required.
+
+
+ If the standby promotion succeeds, the server will not need to be
+ restarted. However any other standbys will need to follow the new server,
+ by using ; if repmgrd
+ is active, it will handle this automatically.
+
+
+
+
+ Example
+
+
$ repmgr -f /etc/repmgr.conf standby promote
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -l /var/log/postgres/startup.log -w -D '/var/lib/postgres/data' promote"
server promoting
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
- DETAIL: server "node2" (ID: 2) was successfully promoted to primary
-
-
-
+ DETAIL: server "node2" (ID: 2) was successfully promoted to primary
+
+
+
diff --git a/doc/repmgr-standby-register.sgml b/doc/repmgr-standby-register.sgml
index 49acb1e6..3ef72197 100644
--- a/doc/repmgr-standby-register.sgml
+++ b/doc/repmgr-standby-register.sgml
@@ -1,29 +1,43 @@
-
- repmgr standby register
- repmgr standby register
-
- repmgr standby register adds a standby's information to
- the &repmgr; metadata. This command needs to be executed to enable
- promote/follow operations and to allow repmgrd to work with the node.
- An existing standby can be registered using this command. Execute with the
- --dry-run option to check what would happen without actually registering the
- standby.
-
+
+
+ repmgr standby register
+
-
+
+ repmgr standby register
+
+
+
+ repmgr standby register
+ add a standby's information to the &repmgr; metadata
+
+
+
+ Description
- If providing the configuration file location with -f/--config-file,
- avoid using a relative path, as &repmgr; stores the configuration file location
- in the repmgr metadata for use when &repmgr; is executed remotely (e.g. during
- ). &repmgr; will attempt to convert the
- a relative path into an absolute one, but this may not be the same as the path you
- would explicitly provide (e.g. ./repmgr.conf might be converted
- to /path/to/./repmgr.conf, whereas you'd normally write
- /path/to/repmgr.conf).
+ repmgr standby register adds a standby's information to
+ the &repmgr; metadata. This command needs to be executed to enable
+ promote/follow operations and to allow repmgrd to work with the node.
+ An existing standby can be registered using this command. Execute with the
+ --dry-run option to check what would happen without actually registering the
+ standby.
-
-
+
+
+ If providing the configuration file location with -f/--config-file,
+ avoid using a relative path, as &repmgr; stores the configuration file location
+ in the repmgr metadata for use when &repmgr; is executed remotely (e.g. during
+ ). &repmgr; will attempt to convert the
+ a relative path into an absolute one, but this may not be the same as the path you
+ would explicitly provide (e.g. ./repmgr.conf might be converted
+ to /path/to/./repmgr.conf, whereas you'd normally write
+ /path/to/repmgr.conf).
+
+
+
+
+ Waiting for the registration to propagate to the standby
Depending on your environment and workload, it may take some time for
@@ -37,9 +51,9 @@
until the record is synchronised before exiting. An optional timeout (in
seconds) can be added to this option (e.g. --wait-sync=60).
-
+
-
+ Registering an inactive node
Under some circumstances you may wish to register a standby which is not
@@ -59,5 +73,5 @@
When used with repmgr standby register, care should be taken that use of the
-F/--force option does not result in an incorrectly configured cluster.
-
-
+
+
diff --git a/doc/repmgr-standby-switchover.sgml b/doc/repmgr-standby-switchover.sgml
index af84a1d5..5802a626 100644
--- a/doc/repmgr-standby-switchover.sgml
+++ b/doc/repmgr-standby-switchover.sgml
@@ -1,27 +1,50 @@
-
+repmgr standby switchover
- repmgr standby switchover
-
- Promotes a standby to primary and demotes the existing primary to a standby.
- This command must be run on the standby to be promoted, and requires a
- passwordless SSH connection to the current primary.
-
-
- If other standbys are connected to the demotion candidate, &repmgr; can instruct
+
+
+ repmgr standby switchover
+
+
+
+ repmgr standby switchover
+ promote a standby to primary and demote the existing primary to a standby
+
+
+
+ Description
+
+
+ Promotes a standby to primary and demotes the existing primary to a standby.
+ This command must be run on the standby to be promoted, and requires a
+ passwordless SSH connection to the current primary.
+
+
+ If other standbys are connected to the demotion candidate, &repmgr; can instruct
these to follow the new primary if the option --siblings-follow
- is specified.
-
-
- Execute with the --dry-run option to test the switchover as far as
- possible without actually changing the status of either node.
-
-
- repmgrd should not be active on any nodes while a switchover is being
- executed. This restriction may be lifted in a later version.
-
-
- For more details see the section .
-
-
+ is specified.
+
+
+
+
+ Execution
+
+
+ Execute with the --dry-run option to test the switchover as far as
+ possible without actually changing the status of either node.
+
+
+ repmgrd should not be active on any nodes while a switchover is being
+ executed. This restriction may be lifted in a later version.
+
+
+
+
+ See also
+
+ For more details see the section .
+
+
+
+
diff --git a/doc/repmgr-standby-unregister.sgml b/doc/repmgr-standby-unregister.sgml
index b3576946..72fafd94 100644
--- a/doc/repmgr-standby-unregister.sgml
+++ b/doc/repmgr-standby-unregister.sgml
@@ -1,29 +1,46 @@
-
- repmgr standby unregister
- repmgr standby unregister
-
- Unregisters a standby with `repmgr`. This command does not affect the actual
- replication, just removes the standby's entry from the &repmgr; metadata.
-
-
- To unregister a running standby, execute:
-
- repmgr standby unregister -f /etc/repmgr.conf
-
-
- This will remove the standby record from &repmgr;'s internal metadata
- table (repmgr.nodes). A standby_unregister
- event notification will be recorded in the repmgr.events table.
-
-
- If the standby is not running, the command can be executed on another
- node by providing the id of the node to be unregistered using
- the command line parameter --node-id, e.g. executing the following
- command on the primary server will unregister the standby with
- id 3:
-
- repmgr standby unregister -f /etc/repmgr.conf --node-id=3
-
-
-
+
+
+ repmgr standby unregister
+
+
+
+ repmgr standby unregister
+
+
+
+ repmgr standby unregister
+ remove a standby's information from the &repmgr; metadata
+
+
+
+ Description
+
+ Unregisters a standby with &repmgr;. This command does not affect the actual
+ replication, just removes the standby's entry from the &repmgr; metadata.
+
+
+
+
+ Execution
+
+ To unregister a running standby, execute:
+
+ repmgr standby unregister -f /etc/repmgr.conf
+
+
+ This will remove the standby record from &repmgr;'s internal metadata
+ table (repmgr.nodes). A standby_unregister
+ event notification will be recorded in the repmgr.events table.
+
+
+ If the standby is not running, the command can be executed on another
+ node by providing the id of the node to be unregistered using
+ the command line parameter --node-id, e.g. executing the following
+ command on the primary server will unregister the standby with
+ id 3:
+
+ repmgr standby unregister -f /etc/repmgr.conf --node-id=3
+
+
+