The upgrade process consists of two steps:
repmgr.conf configuration files
CREATE EXTENSION (PostgreSQL 12 and earlier)
A script is provided to assist with converting repmgr.conf.
The schema upgrade (which converts the repmgr metadata into a packaged PostgreSQL extension) is normally carried out automatically when the repmgr extension is created.
The shared library has been renamed from repmgr_funcs to
repmgr - if it's set in shared_preload_libraries
in postgresql.conf it will need to be updated to the new name:
shared_preload_libraries = 'repmgr'
With a completely new repmgr version, we've taken the opportunity
to rename some configuration items for
clarity and consistency, both between the configuration file and
the column names in repmgr.nodes
(e.g. node to node_id), and
also for consistency with PostgreSQL naming conventions
(e.g. loglevel to log_level).
Other configuration items have been changed to command line options, and vice-versa, e.g. to avoid hard-coding items such as a a node's upstream ID, which might change over time.
repmgr will issue a warning about deprecated/altered options.
Following parameters have been added:
data_directory: this is mandatory and must
contain the path to the node's data directorymonitoring_history: this replaces the
repmgrd command line option
--monitoring-history
Following parameters have been renamed:
Table 10.1. Parameters renamed in repmgr4
| repmgr3 | repmgr4 |
|---|---|
node | node_id |
loglevel | log_level |
logfacility | log_facility |
logfile | log_file |
barman_server | barman_host |
master_reponse_timeout | async_query_timeout |
From repmgr 4, barman_server refers
to the server configured in Barman (in repmgr 3, the deprecated
cluster parameter was used for this);
the physical Barman hostname is configured with
barman_host (see Section 5.1.1
for details).
Following parameters have been removed:
cluster: is no longer required and will
be ignored.upstream_node: is replaced by the
command-line parameter --upstream-node-id
To assist with conversion of repmgr.conf files, a Perl script
is provided in contrib/convert-config.pl.
Use like this:
$ ./convert-config.pl /etc/repmgr.conf
node_id=2
node_name='node2'
conninfo='host=node2 dbname=repmgr user=repmgr connect_timeout=2'
pg_ctl_options='-l /var/log/postgres/startup.log'
rsync_options='--exclude=postgresql.local.conf --archive'
log_level='INFO'
pg_basebackup_options='--no-slot'
data_directory=''
The converted file is printed to STDOUT and the original file is not
changed.
Please note that the the conversion script will add an empty
placeholder parameter for data_directory, which
is a required parameter from repmgr 4. This must be manually modified to contain
the correct data directory.
Ensure repmgrd is not running, or any cron jobs which execute the
repmgr binary.
Install the latest repmgr package; any repmgr 3.x packages
should be uninstalled (if not automatically uninstalled already by your packaging system).
If you don't care about any data from the existing repmgr installation,
(e.g. the contents of the events and monitoring
tables), the following steps can be skipped; proceed to Section 10.3.4.
If your repmgr version is 3.1.1 or earlier, you will need to update the schema to the latest version in the 3.x series (3.3.2) before converting the installation to repmgr 4.
To do this, apply the following upgrade scripts as appropriate for your current version:
For more details see the repmgr 3 upgrade notes.
In the database used by the existing repmgr installation, execute:
CREATE EXTENSION repmgr FROM unpackaged
This will move and convert all objects from the existing schema
into the new, standard repmgr schema.
There must be only one schema matching repmgr_% in the
database, otherwise this step may not work.
Beginning with PostgreSQL 13, the CREATE EXTENSION ... FROM unpackaged
syntax is no longer available. In the unlikely event you have ended up with an
installation running PostgreSQL 13 or later and containing the legacy repmgr
schema, there is no convenient way of upgrading this; instead you'll just need
to re-register the nodes as detailed in the following section,
which will create the repmgr extension automatically.
Any historical data you wish to retain (e.g. the contents of the events
and monitoring tables) will need to be exported manually.
This is necessary to update the repmgr metadata with some additional items.
On the primary node, execute e.g.
repmgr primary register -f /etc/repmgr.conf --force
If not already present (e.g. after executing CREATE EXTENSION repmgr FROM unpackaged),
the repmgr extension will be automatically created by repmgr primary register.
On each standby node, execute e.g.
repmgr standby register -f /etc/repmgr.conf --force
Check the data is updated as expected by examining the repmgr.nodes
table; restart repmgrd if required.
The original repmgr_$cluster schema can be dropped at any time.
Once the cluster has been registered with the current repmgr version, the legacy
repmgr_$cluster schema can be dropped at any time with:
DROP SCHEMA repmgr_$cluster CASCADE
(substitute $cluster with the value of the clustername
variable used in repmgr 3.x).