repmgrd configuration To use repmgrd, its associated function library must be included in postgresql.conf with: shared_preload_libraries = 'repmgr' Changing this setting requires a restart of PostgreSQL; for more details see the PostgreSQL documentation. Additionally the following repmgrd options *must* be set in repmgr.conf (adjust configuration file locations as appropriate): failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file' follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n' Note that the --log-to-file option will cause output generated by the &repmgr; command, when executed by repmgrd, to be logged to the same destination configured to receive log output for repmgrd. See repmgr.conf.sample for further repmgrd-specific settings. When failover is set to automatic, upon detecting failure of the current primary, repmgrd will execute either promote_command (if the current server is to become the new primary) or follow_command (if the current serverneeds to follow another server which has become the new primary. These commands can be any valid shell script which results in one of these two actions happening, but if &repmgr;'s standby follow or standby promote commands are not executed (either directly as shown here, or from a script which performs other actions), the &repmgr; metadata will not be updated and &repmgr; will no longer function reliably. The follow_command should provide the --upstream-node-id=%n option to repmgr standby follow; the %n will be replaced by repmgrd with the ID of the new primary node. If this is not provided, &repmgr; will attempt to determine the new primary by itself, but if the original primary comes back online after the new primary is promoted, there is a risk that repmgr standby follow will result in the node continuing to follow the original primary. In addition to the &repmgr; configuration settings, parameters in the conninfo string influence how &repmgr; makes a network connection to PostgreSQL. In particular, if another server in the replication cluster is unreachable at network level, system network settings will influence the length of time it takes to determine that the connection is not possible. In particular explicitly setting a parameter for connect_timeout should be considered; the effective minimum value of 2 (seconds) will ensure that a connection failure at network level is reported as soon as possible, otherwise depending on the system settings (e.g. tcp_syn_retries in Linux) a delay of a minute or more is possible. For further details on conninfo network connection parameters, see the PostgreSQL documentation. service commands repmgrd By default, &repmgr; will use pg_ctl to stop, start, restart, reloadthe PostgreSQL cluster. However, if installed from a package, particularly under pg_ctl, it's advisable to specify the appropriate service commands to perform these options. To do this, specify the appropriate command for each action in repmgr.conf using the following configuration parameters: service_start_command service_stop_command service_restart_command service_reload_command It's also possible to specify a service_promote_command; this overrides any value contained in the setting promote_command. This is intended for systems which provide a package-level promote command, such as Debian's pg_ctlcluster. To confirm which command &repmgr; will execute for each action, use repmgr node service --list --action=..., e.g.: repmgr -f /etc/repmgr.conf node service --list --action=stop repmgr -f /etc/repmgr.conf node service --list --action=start repmgr -f /etc/repmgr.conf node service --list --action=restart repmgr -f /etc/repmgr.conf node service --list --action=reload These commands will be executed by the system user which &repmgr; runs as (usually postgres) and will probably require passwordless sudo access to be able to execute the command. For example, using systemd on CentOS 7, the service commands can be set as follows: service_start_command = 'sudo systemctl start postgresql-9.6' service_stop_command = 'sudo systemctl stop postgresql-9.6' service_restart_command = 'sudo systemctl restart postgresql-9.6' and /etc/sudoers should be set as follows: Defaults:postgres !requiretty postgres ALL = NOPASSWD: /usr/bin/systemctl stop postgresql-9.6, \ /usr/bin/systemctl start postgresql-9.6, \ /usr/bin/systemctl restart postgresql-9.6 If using systemd, ensure you have RemoteIPC set to off. See the systemd entry in the PostgreSQL wiki for details. To ensure the current repmgrd logfile does not grow indefinitely, configure your system's logrotate to regularly rotate it. Sample configuration to rotate logfiles weekly with retention for up to 52 weeks and rotation forced if a file grows beyond 100Mb: /var/log/postgresql/repmgr-9.6.log { missingok compress rotate 52 maxsize 100M weekly create 0600 postgres postgres }