diff --git a/doc/cloning-standbys.sgml b/doc/cloning-standbys.sgml
index 777b3677..4d409264 100644
--- a/doc/cloning-standbys.sgml
+++ b/doc/cloning-standbys.sgml
@@ -4,7 +4,10 @@
- Barman
+
+ cloning
+ from Barman
+
Cloning a standby from Barman
can use
@@ -159,4 +162,74 @@
+
+
+
+ cloning
+ advanced options
+
+ Advanced cloning options
+
+
+ pg_basebackup options when cloning a standby
+
+ 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 the -c/--fast-checkpoint option.
+ However this may impact performance of the server being cloned from
+ so should be used with care.
+
+
+ Further options can be passed to the pg_basebackup utility via
+ the setting pg_basebackup_options in repmgr.conf.
+ See the PostgreSQL pg_basebackup documentation
+ for more details of available options.
+
+
+
+
+ Managing passwords
+
+ 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, 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. .
+
+
+ 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.
+
+
+
+
+ Separate replication user
+
+ 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 repmgr.nodes
+ table for each node; it no longer needs to be explicitly specified when
+ cloning a node or executing .
+
+
+
+
diff --git a/doc/command-reference.sgml b/doc/command-reference.sgml
index 4fd688cf..2627c5a5 100644
--- a/doc/command-reference.sgml
+++ b/doc/command-reference.sgml
@@ -6,7 +6,10 @@
- repmgr standby clone
+
+ repmgr standby clone
+ cloning
+
repmgr standby clone
repmgr standby clone clones a PostgreSQL node from another
@@ -144,4 +147,40 @@
+
+
+
+ repmgr standby follow
+
+ repmgr standby follow
+
+ Attaches the standby to a new primary. This command requires a valid
+ repmgr.conf file for the standby, either specified
+ explicitly with -f/--config-file or located in a
+ default location; no additional arguments are required.
+
+
+ This command will force a restart of the standby server, which must be
+ running. It can only be used to attach a standby to a new primary node.
+
+
+ To re-add an inactive node to the replication cluster, see
+
+
+
+
+
+
+
+ repmgr node rejoin
+
+ repmgr node rejoin
+
+ Enables a dormant (stopped) node to be rejoined to the replication cluster.
+
+
+ This can optionally use `pg_rewind` to re-integrate a node which has diverged
+ from the rest of the cluster, typically a failed primary.
+
+