diff --git a/doc/filelist.sgml b/doc/filelist.sgml
index c1bed9cb..6587bc05 100644
--- a/doc/filelist.sgml
+++ b/doc/filelist.sgml
@@ -43,6 +43,10 @@
+
+
+
+
diff --git a/doc/repmgr.sgml b/doc/repmgr.sgml
index 1d498ae4..5a79167a 100644
--- a/doc/repmgr.sgml
+++ b/doc/repmgr.sgml
@@ -75,6 +75,12 @@
&switchover;
+
+ Using repmgrd
+ &repmgrd-automatic-failover;
+ &repmgrd-configuration;
+
+
repmgr command reference
diff --git a/doc/repmgrd-automatic-failover.sgml b/doc/repmgrd-automatic-failover.sgml
new file mode 100644
index 00000000..8c28deca
--- /dev/null
+++ b/doc/repmgrd-automatic-failover.sgml
@@ -0,0 +1,12 @@
+
+ Automatic failover with repmgrd
+
+
+ repmgrd is a management and monitoring daemon which runs
+ on each node in a replication cluster. It can automate actions such as
+ failover and updating standbys to follow the new primary, as well as
+ providing monitoring information about the state of each standby.
+
+
+
+
diff --git a/doc/repmgrd-configuration.sgml b/doc/repmgrd-configuration.sgml
new file mode 100644
index 00000000..621161d4
--- /dev/null
+++ b/doc/repmgrd-configuration.sgml
@@ -0,0 +1,51 @@
+
+ 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 one of
+ promote_command or follow_command,
+ depending on whether the current server is to become the new primary, or
+ needs to follow another server which has become the new primary. Note that
+ 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.
+
+
+