As repmgr uses pg_basebackup to clone a standby, it's possible to
provide additional parameters for pg_basebackup to customise the
cloning process.
By default, pg_basebackup performs a checkpoint before beginning the backup
process. However, a normal checkpoint may take some time to complete;
a fast checkpoint can be forced with repmgr standby clone's
-c/--fast-checkpoint option.
Note that this may impact performance of the server being cloned from (typically the primary)
so should be used with care.
If Barman is set up for the cluster, it's possible to clone the standby directly from Barman, without any impact on the server the standby is being cloned from. For more details see Cloning from Barman.
Other options can be passed to pg_basebackup by including them
in the repmgr.conf setting pg_basebackup_options.
Not that by default, repmgr executes pg_basebackup with -X/--wal-method
(PostgreSQL 9.6 and earlier: -X/--xlog-method) set to stream.
From PostgreSQL 9.6, if replication slots are in use, it will also create a replication slot before
running the base backup, and execute pg_basebackup with the
-S/--slot option set to the name of the previously created replication slot.
These parameters can set by the user in pg_basebackup_options, in which case they
will override the repmgr default values. However normally there's no reason to do this.
If using a separate directory to store WAL files, provide the option --waldir
(--xlogdir in PostgreSQL 9.6 and earlier) with the absolute path to the
WAL directory. Any WALs generated during the cloning process will be copied here, and
a symlink will automatically be created from the main data directory.
See the PostgreSQL pg_basebackup documentation for more details of available options.
If replication connections to a standby's upstream server are password-protected, the standby must be able to provide the password so it can begin streaming replication.
The recommended way to do this is to store the password in the postgres system
user's ~/.pgpass file. It's also possible to store the password in the
environment variable PGPASSWORD, however this is not recommended for
security reasons. For more details see the
PostgreSQL password file documentation.
If using a pgpass file, an entry for the replication user (by default the
user who connects to the repmgr database) must
be provided, with database name set to replication, e.g.:
node1:5432:replication:repmgr:12345
If, for whatever reason, you wish to include the password in recovery.conf,
set use_primary_conninfo_password to true in
repmgr.conf. This will read a password set in PGPASSWORD
(but not ~/.pgpass) and place it into the primary_conninfo
string in recovery.conf. Note that PGPASSWORD
will need to be set during any action which causes recovery.conf to be
rewritten, e.g. repmgr standby follow.
It is of course also possible to include the password value in the conninfo
string for each node, but this is obviously a security risk and should be avoided.
From PostgreSQL 9.6, libpq supports the passfile
parameter in connection strings, which can be used to specify a password file other than
the default ~/.pgpass.
To have repmgr write a custom password file in primary_conninfo,
specify its location in passfile in repmgr.conf.
In some circumstances it might be desirable to create a dedicated replication-only
user (in addition to the user who manages the repmgr metadata). In this case,
the replication user should be set in repmgr.conf via the parameter
replication_user; repmgr will use this value when making
replication connections and generating recovery.conf. This
value will also be stored in the parameter repmgr.nodes
table for each node; it no longer needs to be explicitly specified when
cloning a node or executing repmgr standby follow.