This section gives a quick introduction to &repmgr;, including setting up a sample &repmgr; installation and a basic replication cluster. These instructions are not suitable for a production install, as they may not take into account security considerations, proper system administration procedures etc.. The following section will describe how to set up a basic replication cluster with a primary and a standby server using the repmgr command line tool. We'll assume the primary is called node1 with IP address 192.168.1.11, and the standby is called node2 with IP address 192.168.1.12 Following software must be installed on both servers: PostgreSQL repmgr (matching the installed PostgreSQL major version) At network level, connections between the PostgreSQL port (default: 5432) must be possible in both directions. If you want repmgr to copy configuration files which are located outside the PostgreSQL data directory, and/or to test switchover functionality, you will also need passwordless SSH connections between both servers, and rsync should be installed. For testing repmgr, it's possible to use multiple PostgreSQL instances running on different ports on the same computer, with passwordless SSH access to localhost enabled. On the primary server, a PostgreSQL instance must be initialised and running. The following replication settings may need to be adjusted: # Enable replication connections; set this figure to at least one more # than the number of standbys which will connect to this server # (note that repmgr will execute `pg_basebackup` in WAL streaming mode, # which requires two free WAL senders) max_wal_senders = 10 # Ensure WAL files contain enough information to enable read-only queries # on the standby. # # PostgreSQL 9.5 and earlier: one of 'hot_standby' or 'logical' # PostgreSQL 9.6 and later: one of 'replica' or 'logical' # ('hot_standby' will still be accepted as an alias for 'replica') # # See: https://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-LEVEL wal_level = 'hot_standby' # Enable read-only queries on a standby # (Note: this will be ignored on a primary but we recommend including # it anyway) hot_standby = on # Enable WAL file archiving archive_mode = on # Set archive command to a script or application that will safely store # you WALs in a secure place. /bin/true is an example of a command that # ignores archiving. Use something more sensible. archive_command = '/bin/true' # If you have configured `pg_basebackup_options` # in `repmgr.conf` to include the setting `--xlog-method=fetch` (from # PostgreSQL 10 `--wal-method=fetch`), *and* you have not set # `restore_command` in `repmgr.conf`to fetch WAL files from another # source such as Barman, you'll need to set `wal_keep_segments` to a # high enough value to ensure that all WAL files generated while # the standby is being cloned are retained until the standby starts up. # # wal_keep_segments = 5000 Rather than editing these settings in the default postgresql.conf file, create a separate file such as postgresql.replication.conf and include it from the end of the main configuration file with: include 'postgresql.replication.conf. Create a dedicated PostgreSQL superuser account and a database for the `repmgr` metadata, e.g. createuser -s repmgr createdb repmgr -O repmgr For the examples in this document, the name repmgr will be used for both user and database, but any names can be used. For the sake of simplicity, the repmgr user is created as a superuser. If desired, it's possible to create the repmgr user as a normal user. However for certain operations superuser permissions are requiredl; in this case the command line option --superuser can be provided to specify a superuser. It's also assumed that the repmgr user will be used to make the replication connection from the standby to the primary; again this can be overridden by specifying a separate replication user when registering each node. Ensure the `repmgr` user has appropriate permissions in pg_hba.conf and can connect in replication mode; pg_hba.conf should contain entries similar to the following: local replication repmgr trust host replication repmgr 127.0.0.1/32 trust host replication repmgr 192.168.1.0/24 trust local repmgr repmgr trust host repmgr repmgr 127.0.0.1/32 trust host repmgr repmgr 192.168.1.0/24 trust Adjust according to your network environment and authentication requirements. On the standby, do not create a PostgreSQL instance, but do ensure the destination data directory (and any other directories which you want PostgreSQL to use) exist and are owned by the postgres system user. Permissions should be set to 0700 (drwx------). Check the primary database is reachable from the standby using psql: psql 'host=node1 user=repmgr dbname=repmgr connect_timeout=2' &repmgr; stores connection information as libpq connection strings throughout. This documentation refers to them as conninfo strings; an alternative name is DSN (data source name). We'll use these in place of the -h hostname -d databasename -U username syntax. Create a repmgr.conf file on the primary server. The file must contain at least the following parameters: node_id=1 node_name=node1 conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2' data_directory='/var/lib/postgresql/data' repmgr.conf should not be stored inside the PostgreSQL data directory, as it could be overwritten when setting up or reinitialising the PostgreSQL server. See sections on and for further details about repmgr.conf.