configuration prerequisites configuration ssh Following software must be installed on both servers: PostgreSQL repmgr At network level, connections between the PostgreSQL port (default: 5432) must be possible between all nodes. Passwordless SSH connectivity between all servers in the replication cluster is not required, but is necessary in the following cases: if you need &repmgr; to copy configuration files from outside the PostgreSQL data directory (as is the case with e.g. Debian packages); in this case rsync must also be installed on all servers. to perform switchover operations when executing repmgr cluster matrix and repmgr cluster crosscheck Consider setting ConnectTimeout to a low value in your SSH configuration. This will make it faster to detect any SSH connection errors. configuration PostgreSQL PostgreSQL configuration The following PostgreSQL configuration parameters may need to be changed in order for &repmgr; (and replication itself) to function correctly. hot_standby hot_standby PostgreSQL configuration hot_standby must always be set to on, as &repmgr; needs to be able to connect to each server it manages. Note that hot_standby defaults to on from PostgreSQL 10 and later; in PostgreSQL 9.6 and earlier, the default was off. PostgreSQL documentation: hot_standby. wal_level wal_level PostgreSQL configuration wal_level must be one of replica or logical (PostgreSQL 9.5 and earlier: one of hot_standby or logical). PostgreSQL documentation: wal_level. max_wal_senders max_wal_senders PostgreSQL configuration max_wal_senders must be set to a value of 2 or greater. In general you will need one WAL sender for each standby which will attach to the PostgreSQL instance; additionally &repmgr; will require two free WAL senders in order to clone further standbys. max_wal_senders should be set to an appropriate value on all PostgreSQL instances in the replication cluster which may potentially become a primary server or (in cascading replication) the upstream server of a standby. PostgreSQL documentation: max_wal_senders. max_replication_slots max_replication_slots PostgreSQL configuration If you are intending to use replication slots, max_replication_slots must be set to a non-zero value. max_replication_slots should be set to an appropriate value on all PostgreSQL instances in the replication cluster which may potentially become a primary server or (in cascading replication) the upstream server of a standby. PostgreSQL documentation: max_replication_slots. wal_log_hints wal_log_hints PostgreSQL configuration If you are intending to use pg_rewind, and the cluster was not initialised using data checksums, you may want to consider enabling wal_log_hints. For more details see . PostgreSQL documentation: wal_log_hints. archive_mode archive_mode PostgreSQL configuration We suggest setting archive_mode to on (and archive_command to /bin/true; see below) even if you are currently not planning to use WAL file archiving. This will make it simpler to set up WAL file archiving if it is ever required, as changes to archive_mode require a full PostgreSQL server restart, while archive_command changes can be applied via a normal configuration reload. However, &repmgr; itself does not require WAL file archiving. PostgreSQL documentation: archive_mode. archive_command archive_command PostgreSQL configuration If you have set archive_mode to on but are not currently planning to use WAL file archiving, set archive_command to a command which does nothing but returns true, such as /bin/true. See above for details. PostgreSQL documentation: archive_command. wal_keep_segments wal_keep_segments PostgreSQL configuration Normally there is no need to set wal_keep_segments (default: 0), as it is not a reliable way of ensuring that all required WAL segments are available to standbys. Replication slots and/or an archiving solution such as Barman are recommended to ensure standbys have a reliable source of WAL segments at all times. The only reason ever to set wal_keep_segments is you have you have configured pg_basebackup_options in repmgr.conf to include the setting --wal-method=fetch (PostgreSQL 9.6 and earlier: --xlog-method=fetch) and you have not set restore_command in repmgr.conf to fetch WAL files from a reliable source such as Barman, in which case you'll need to set wal_keep_segments to a sufficiently high number to ensure that all WAL files required by the standby are retained. However we do not recommend managing replication in this way. PostgreSQL documentation: wal_keep_segments. See also the PostgreSQL configuration section in the Quick-start guide. &configuration-file; &configuration-file-required-settings; &configuration-file-log-settings; &configuration-file-service-commands; configuration database user permissions &repmgr; will create an extension database containing objects for administering &repmgr; metadata. The user defined in the conninfo setting must be able to access all objects. Additionally, superuser permissions are required to install the &repmgr; extension. The easiest way to do this is create the &repmgr; user as a superuser, however if this is not desirable, the &repmgr; user can be created as a normal user and a superuser specified with --superuser when registering a &repmgr; node.