diff --git a/doc/configuration.sgml b/doc/configuration.sgml
index 48817622..af60ce24 100644
--- a/doc/configuration.sgml
+++ b/doc/configuration.sgml
@@ -61,6 +61,229 @@
+
+
+ configuration
+ PostgreSQL
+
+
+
+ PostgreSQL configuration
+
+
+ PostgreSQL configuration for &repmgr;
+
+ The following PostgreSQL configuration parameters may need to be changed in order
+ for &repmgr; (and replication itself) to function correctly.
+
+
+
+
+
+
+
+ hot_standby
+ PostgreSQL configuration
+
+
+
+
+
+ must always be set to on, as &repmgr; needs
+ to be able to connect to each server it manages.
+
+
+ Note that defaults to on from PostgreSQL 10
+ and later; in PostgreSQL 9.6 and earlier, the default was off.
+
+
+ PostgreSQL documentation: hot_standby.
+
+
+
+
+
+
+
+ wal_level
+ PostgreSQL configuration
+
+
+
+
+
+ must be one of or
+ (PostgreSQL 9.5 and earlier: one of or ).
+
+
+ PostgreSQL documentation: wal_level.
+
+
+
+
+
+
+
+ max_wal_senders
+ PostgreSQL configuration
+
+
+
+
+
+ must be set to a value of 2 or greater.
+ In general you will need one WAL sender for each standby which will attach to the PostgreSQL
+ instance; additionally &repmgr; will require two free WAL senders in order to clone further
+ standbys.
+
+
+ should be set to an appropriate value on all PostgreSQL
+ instances in the replication cluster which may potentially become a primary server or
+ (in cascading replication) the upstream server of a standby.
+
+
+ PostgreSQL documentation: max_wal_senders.
+
+
+
+
+
+
+
+ max_replication_slots
+ PostgreSQL configuration
+
+
+
+
+
+ If you are intending to use replication slots,
+ must be set to a non-zero value.
+
+
+ should be set to an appropriate value on all PostgreSQL
+ instances in the replication cluster which may potentially become a primary server or
+ (in cascading replication) the upstream server of a standby.
+
+
+ PostgreSQL documentation: max_replication_slots.
+
+
+
+
+
+
+
+
+ wal_log_hints
+ PostgreSQL configuration
+
+
+
+
+ If you are intending to use pg_rewind,
+ and the cluster was not initialised using data checksums, you may want to consider enabling
+ .
+
+
+ For more details see .
+
+
+ PostgreSQL documentation: wal_log_hints.
+
+
+
+
+
+
+
+ archive_mode
+ PostgreSQL configuration
+
+
+
+
+
+ We suggest setting to on (and
+ to /bin/true; see below)
+ even if you are currently not planning to use WAL file archiving.
+
+
+ This will make it simpler to set up WAL file archiving if it is ever required,
+ as changes to require a full PostgreSQL server
+ restart, while changes can be applied via a normal
+ configuration reload.
+
+
+ However, &repmgr; itself does not require WAL file archiving.
+
+
+ PostgreSQL documentation: archive_mode.
+
+
+
+
+
+
+
+ archive_command
+ PostgreSQL configuration
+
+
+
+
+
+ If you have set to on but are not currently planning
+ to use WAL file archiving, set to a command which does nothing but returns
+ true, such as /bin/true. See above for details.
+
+
+ PostgreSQL documentation: archive_command.
+
+
+
+
+
+
+
+
+ wal_keep_segments
+ PostgreSQL configuration
+
+
+
+
+
+ Normally there is no need to set (default: 0), as it
+ is not a reliable way of ensuring that all required WAL segments are available to standbys.
+ Replication slots and/or an archiving solution such as Barman are recommended to ensure standbys have a reliable
+ source of WAL segments at all times.
+
+
+ The only reason ever to set is you have
+ you have configured
+ in repmgr.conf to include the setting --wal-method=fetch
+ (PostgreSQL 9.6 and earlier: --xlog-method=fetch)
+ and you have not set
+ in repmgr.conf to fetch WAL files from a reliable source such as Barman,
+ in which case you'll need to set
+ to a sufficiently high number to ensure that all WAL files required by the standby
+ are retained. However we do not recommend managing replication in this way.
+
+
+ PostgreSQL documentation: wal_keep_segments.
+
+
+
+
+
+
+ See also the PostgreSQL configuration section in the
+ Quick-start guide.
+
+
+
+
diff --git a/doc/quickstart.sgml b/doc/quickstart.sgml
index f2a6be7e..356e850f 100644
--- a/doc/quickstart.sgml
+++ b/doc/quickstart.sgml
@@ -68,7 +68,7 @@
-
+ PostgreSQL configuration
On the primary server, a PostgreSQL instance must be initialised and running.
@@ -83,6 +83,13 @@
max_wal_senders = 10
+ # Enable replication slots; set this figure to at least one more
+ # than the number of standbys which will connect to this server.
+ # Note that repmgr will only make use of replication slots if
+ # "use_replication_slots" is set to "true" in repmgr.conf
+
+ max_replication_slots = 0
+
# Ensure WAL files contain enough information to enable read-only queries
# on the standby.
#
@@ -107,16 +114,6 @@
# 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
@@ -131,6 +128,9 @@
and the cluster was not initialised using data checksums, you may want to consider enabling
wal_log_hints; for more details see .
+
+ See also the PostgreSQL configuration section in the repmgr configuaration guide.
+