1 Configuration File
1.1 Configuration file format
repmgr.conf is a plain text file containing one parameter/value combination per line.
White spaces are irrelevant (except within quoted parameter values), and blank lines are ignored. #Specifies the remainder of the line as a comment. Parameter values that are not simple identifiers or numbers should be enclosed in single quotes.
To embed single quotes in a parameter value, write double quotes (preferred) or backslash quotes.
Valid file example repmgr.conf:
# repmgr.conf node_id=1 node_name= node1 conninfo ='host=node1 dbname=repmgr user=repmgr connect_timeout=2' data_directory = '/var/lib/pgsql/12/data'
1.2 Configuration file inclusion directives
Starting with repmgr 5.2, configuration files can contain the following include directives:
include: Includes the specified file, which can be an absolute path or a path relative to the current file.include_if_exists: Include the specified file. The file is specified as an absolute path or a path relative to the current file. However, if it does not exist, no error will be raised.include_dir: Include the specified directory with the suffix.conf. The directory is specified as an absolute path or a path relative to the current file.
They behave exactly like PostgreSQL configuration file handling; see the PostgreSQL documentation for more details.
1.3 Configuration file location
Configuration files will be searched in the following locations:
-
-f/--config-fileThe configuration file specified by the command line option -
The location specified by the package maintainer (if repmgr is installed from the package and the package maintainer has specified the configuration file location)
-
repmgr.confis in the local directory -
/etc/repmgr.conf -
pg_config –directory reported by sysconfdir
Note that if a file is explicitly specified using -f/--config-file, an error will be raised if the file is not found or is not readable, and no attempt will be made to check the default location; This is to prevent repmgr from accidentally reading the wrong configuration file
1.4 Configuration file items
The following sections document some parts of the configuration file:
1.4 .1 required configuration files
Each repmgr.conf file must contain the following parameters:
node_id( int)
A unique integer greater than zero that identifies a node.
node_name( string)
An arbitrary (but unique) string; we recommend using the server’s hostname or other identifier explicitly associated with the server to avoid confusion. Avoid choosing a name that reflects the node’s current role, for example, primary or standby1 because roles can change, and if you end up with a solution that calls the current primary node standby1 (for example), things can be confusing to say the least.
The string has a maximum length of 63 characters and should contain only printable ASCII characters.
conninfo( string)
Database connection information as a conninfo string. All servers in the cluster must be able to connect to the local node using this string.
For more information about the conninfo string, see the Connection Strings section in the PosgreSQL documentation.
If you are using repmgrd, consider setting connect_timeout explicitly in the conninfo string to determine the length of time that elapses before a network connection attempt is abandoned; see the PostgreSQL documentation for details .
data_directory( string)
The node’s data directory. repmgr is required to perform this operation when the PostgreSQL instance is not running and there is no other way to determine the data directory.
1.4 .2 Optional configuration file
config_directory( string)
postgresql.confIf the PostgreSQL configuration file is located outside the data directory, specify the directory where the main file is located.
This allows an external configuration file directory to be provided explicitly, which if set is passed to pg_ctl as the -D argument. Otherwise pg_ctl will default to the data directory, which will cause some operations to fail if the configuration file does not exist.
replication_user( string)
The PostgreSQL user to establish a replication connection with. If the default value is set, it is the user defined in conninfo
replication_type( string)
Must be physical (default).
location( string)
An arbitrary string that defines the location of the node; this is used during failover to check the visibility of the current primary node.
use_replication_slots( boolean)
Whether to use physical replication slots.
ssh_options( string)
Options appended to the command when executed by repmgrssh.
We recommend adding -q to suppress any redundant SSH chat (such as login banners) along with an explicit ConnectTimeout value, for example:
ssh_options='-q -o ConnectTimeout=10'
pg_bindir( string)
Path to the PostgreSQL binary directory (location of pg_ctl, pg_basebackup, etc.). PATH is only required if these are not present on the system.
1.5 Log settings
By default, repmgr and repmgrd write log output to STDERR. Alternative log destinations (file or syslog) can be specified.
log_level( string)
The level of log output, the default is INFO. Optional values:
DEBUG, INFO, NOTICE, WARNING, ERROR, ALERT, CRIT, EMERG.
Please note that this DEBUG will produce extensive logging output and should not be enabled in normal use.
log_facility( string)
Logging tool: Optional values are STDERR (default), or for syslog, optional values are: LOCAL0, LOCAL1, ..., LOCAL7, USER.
log_file( string)
If log_facility is set to STDERR, log output can be redirected to a specified file.
See Section 13.4 for information on configuring log rotation.
log_status_interval( integer)
This setting causes repmgrd to emit status log lines at specified intervals (in seconds, default 300) describing the current state of repmgrd, for example:
[2018-07-12 00:47:32] [INFO] monitoring connection to upstream node "node1" (ID: 1)
log_level=info log_facility=STDERR log_file='/home/storage/repmgr/repmgr.log' log_status_interval=600
1.6 Server command parameters
In some cases, repmgr (and repmgrd) need to be able to stop, start, or restart PostgreSQL. Repmgr commands repmgr standby follow, repmgr standby switchover and repmgr node rejoin. The above commands are required.
By default, repmgr will use PostgreSQL’s pg_ctl program to control the PostgreSQL server. However, this can cause various problems, especially when installing PostgreSQL from a package, and especially when using systemd.
Special Note:
If using
systemd, make sure you have
RemoveIPC is set to
off. For more information, see
PostgreSQL documentation section
systemd RemoveIPC and
from the PostgreSQL wiki
systemd entry.
Related parameters
service_start_command='pg_ctl -D /home/storage/pgsql/data -l /home/storage/pgsql/data/server.log start' service_stop_command='pg_ctl -D /home/storage/pgsql/data -l /home/storage/pgsql/data/server.log stop' service_restart_command='pg_ctl -D /home/storage/pgsql/data -l /home/storage/pgsql/data/server.log restart' service_reload_command='pg_ctl -D /home/storage/pgsql/data -l /home/storage/pgsql/data/server.log reload'
You can use the following command to view the real PG command
repmgr -f /etc/repmgr.conf node service --list-actions --action=stop repmgr -f /etc/repmgr.conf node service --list-actions --action=start repmgr -f /etc/repmgr.conf node service --list-actions --action=restart repmgr -f /etc/repmgr.conf node service --list-actions --action=reload
1.7 User Permissions
If the user has superuser permissions, there is no need to grant other permissions.
If using superuser, the following permissions are required:
1.7.1 Replication role
repmgr requires a user with the REPLICATION role to create replication connections and manage replication slots
1.7.2. Database roles
Non-superuser users also need to be members of the following predefined visual roles
pg_read_all_stats(querypg_stat_replication and executeexecutepg_database_size()on all databases)pg_read_all_settings(to access thedata_directorysetting)
1.7.3. Extension creation
1.7.4. Function permissions
1.7.5. repmgr actions requiring a superuser
1.7.6. repmgr commands with –superuser option
1.8 Password Management
PostgreSQL provides three ways of providing passwords:
- Include the password in the string
conninfo(e.g. “host=node1 dbname=repmgr user=repmgr password=foo“) - Export passwords as environment variables (
PGPASSWORD) - Store passwords in a dedicated password file
We strongly recommend not to include passwords in the string conninfo, as this will cause the database password to be exposed in various places, including the files repmgr.conf, repmgr.nodes tables, any output generated by repmgr listing node conninfo strings (such as repmgr cluster show) and in repmgr log files, especially in log_level=DEBUG.
Exporting the password as an environment variable ( PGPASSWORD) is considered less secure, but the PostgreSQL documentation explicitly advises against it:
The safest option for managing passwords is to use a dedicated password file
The most secure way to store passwords is in a password file, which by default is ~/.pgpass. This file can only be read by the system user who owns the file. and PostgreSQL will refuse to use the file unless read/write permissions are restricted to the file owner. The passwords contained in the file will not be directly accessible by repmgr (or any other libpq-based client software, such as psql).
See the PostgreSQL password file documentation for complete details.
For use with repmgr, ~/.pgpass must have two entries for each node in the replication cluster: one for the repmgr user accessing the repmgr metabase, and one for the replication connection (whether Use a dedicated replication user). This file must exist on every node in the replication cluster.
Example file of a 3-node PG cluster managed by repmgr:
node1:5432:repmgr:repmgr:foo node1:5432:replication:repmgr:foo node2:5432:repmgr:repmgr:foo node2:5432:replication:repmgr:foo node3:5432:repmgr:repmgr:foo node3:5432:replication:repmgr:foo
1.6 complete configuration file
https://raw.githubusercontent.com/EnterpriseDB/repmgr/master/repmgr.conf.sample