Remove any non-repmgrd specific items.
parse_config() already sanity-checks the values so no need to
recheck. Refactor parse_config() so when called by reload_config()
it won't exit if errors are encountered.
When checking the new standby's record in pg_stat_replication, keep
polling until the expected status is reported, and only give up
after a timeout was exceeded.
Previously repmgr would report an error if status was "startup",
even though this is not a problem.
In Barman mode the data directory is created early containing a temporary
directory needed to hold temporary files while cloning from the Barman
server. In other modes we might not know the data directory location until
connecting to the source server, so its creation happens later. In Barman
mode ensure that step is skipped.
Place elements in a sensible order and split the associated initializer
macro over multiple lines for easier editing.
Also move a few related global variables into to the structure to keep
everything in the same place.
Barman 2.0 provides this in a separate, more convenient `barman-cli` package;
document this and add note about previous `barman-wal-restore.py` script.
These are now prefixed with "service_" to emphasize that they're
OS-level commands, not repmgr ones; also added reload and promote
commands:
service_start_command
service_stop_command
service_restart_command
service_reload_command
service_promote_command
GitHub #169
Previously the code assumed repmgr node IDs to be sequential,
which is not guaranteed to be the case. With a non-sequential
list of node IDs, an incorrect node id would be displayed,
and memory accessed beyond the bounds of the matrix array.
The refactored code is considerably less elegant than the original
but will correctly handle a non-sequential sequence of node IDs.
- use the remote user setting, like other SSH-based remote operations
(avoid hardcoding the user name)
- enable `repmgr cluster matrix' to accept the cluster name, node id
and the database connection information instead of requiring repmgr.conf;
this means we don't have to assume that repmgr.conf is in one
of the default locations
We separate the code that builds the cube from the code that displays
it, in preparation for reusing the cube somewhere else, e.g. for
automatic failover detection.
We separate the code that builds the matrix from the code that
displays it, in preparation for reusing the matrix somewhere else,
e.g. for automatic failover detection.
- use the remote user setting, like other SSH-based remote operations
(avoid hardcoding the user name)
- enable `repmgr cluster show` to accept the cluster name and the
database connection information instead of requiring repmgr.conf;
this means we don't have to assume that repmgr.conf is in one
of the default locations
Currently repmgr assumes the SSH hostname will be the same as the
database hostname, and it's easy enough now to extract this
from the node's conninfo string.
We can consider re-adding this in the next release if required.
- The "cluster matrix" command supports CSV mode via the --csv
switch.
- Add the optional ssh_hostname configuration parameter, which is
required by "cluster matrix".
- A corresponding ssh_hostname column has been added to the repl_nodes
table and to the repl_show_nodes view.
The examples of `promote_command` and `follow_command` reference the
`repmgr.conf` file under a different path from the rest of the README.
This makes them consistent with the rest of the README.
