upgrading &repmgr; is updated regularly with point releases (e.g. 4.0.1 to 4.0.2) containing bugfixes and other minor improvements. Any substantial new functionality will be included in a feature release (e.g. 4.0.x to 4.1.x). upgrading repmgr 4.x and later &repmgr; 4.x is implemented as a PostgreSQL extension; normally the upgrade consists of the two following steps: Install the updated package (or compile the updated source) repmgrd (if running) must be restarted. For major releases, e.g. from 4.0.x to 4.1, execute ALTER EXTENSION repmgr UPDATE on the primary node in the database where the &repmgr; extension is installed. This will update the extension metadata and, if necessary, apply changes to the &repmgr; extension objects. Always check the release notes for every release as they may contain upgrade instructions particular to individual versions. Note that it may be necessary to restart the PostgreSQL server if the upgrade contains changes to the shared object file used by repmgrd; check the release notes for details. upgrading pg_upgrade pg_upgrade pg_upgrade requires that if any functions are dependent on a shared library, this library must be present in both the old and new installations before pg_upgrade can be executed. To minimize the risk of any upgrade issues (particularly if an upgrade to a new major &repmgr; version is involved), we recommend upgrading &repmgr; on the old server before running pg_upgrade to ensure that old and new versions are the same. This issue applies to any PostgreSQL extension which has dependencies on a shared library. For further details please see the pg_upgrade documentation. If replication slots are in use, bear in mind these will not be recreated by pg_upgrade. These will need to be recreated manually. upgrading from repmgr 3.x The upgrade process consists of two steps: converting the repmgr.conf configuration files upgrading the repmgr schema using CREATE EXTENSION 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 directory monitoring_history: this replaces the repmgrd command line option --monitoring-history Following parameters have been renamed: 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 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 in repmgr4 and which must be provided. Ensure repmgrd is not running, or any cron jobs which execute the repmgr binary. Install repmgr 4 packages; any repmgr 3.x packages should be uninstalled (if not automatically uninstalled already by your packaging system). 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: repmgr3.0_repmgr3.1.sql repmgr3.1.1_repmgr3.1.2.sql 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. 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 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. If you don't care about any data from the existing &repmgr; installation, (e.g. the contents of the events and monitoring tables), the manual CREATE EXTENSION step can be skipped; just re-register each node, starting with the primary node, and the repmgr extension will be automatically created.