diff --git a/doc/appendix-faq.xml b/doc/appendix-faq.xml index 6248d43f..92c1f18f 100644 --- a/doc/appendix-faq.xml +++ b/doc/appendix-faq.xml @@ -249,16 +249,16 @@ For a standby which has been manually cloned or recovered from an external backup manager such as Barman, the command repmgr standby clone --replication-conf-only - can be used to create the correct recovery.conf file for + can be used to create the correct replication configuration file for use with &repmgr; (and will create a replication slot if required). Once this has been done, register the node as usual. - What does &repmgr; write in <filename>recovery.conf</filename>, and what options can be set there? + What does &repmgr; write in the replication configuration, and what options can be set there? - See section Customising recovery.conf. + See section Customising replication configuration. @@ -366,11 +366,11 @@ - - Why are some values in <filename>recovery.conf</filename> surrounded by pairs of single quotes? + + Why are some values in the filename>recovery.conf</filename> (PostgreSQL 11 and earlier) surrounded by pairs of single quotes? - This is to ensure that user-supplied values which are written as parameter values in recovery.conf - are escaped correctly and do not cause errors when recovery.conf is parsed. + This is to ensure that user-supplied values which are written as parameter values in filename>recovery.conf + are escaped correctly and do not cause errors when the file is parsed. The escaping is performed by an internal PostgreSQL routine, which leaves strings consisting @@ -419,9 +419,9 @@ &repmgrd; can monitor delayed standbys - those set up with recovery_min_apply_delay set to a non-zero value - in recovery.conf - but as it's not currently possible - to directly examine the value applied to the standby, &repmgrd; - may not be able to properly evaluate the node as a promotion candidate. + in the replication configuration. However &repmgrd; does not currently + consider this setting, and therefore may not be able to properly evaluate + the node as a promotion candidate. We recommend that delayed standbys are explicitly excluded from promotion diff --git a/doc/cloning-standbys.xml b/doc/cloning-standbys.xml index a7e44156..fc5a18ab 100644 --- a/doc/cloning-standbys.xml +++ b/doc/cloning-standbys.xml @@ -197,7 +197,7 @@ description = "Main cluster" As a fallback in case streaming replication is interrupted, PostgreSQL can optionally retrieve WAL files from an archive, such as that provided by Barman. This is done by - setting restore_command in recovery.conf to + setting restore_command in the replication configuration to a valid shell command which can retrieve a specified WAL file from the archive. @@ -328,9 +328,9 @@ description = "Main cluster" &repmgr; supports cascading replication. When cloning a standby, set the command-line parameter --upstream-node-id to the node_id of the server the standby should connect to, and - &repmgr; will create recovery.conf to point to it. Note + &repmgr; will create a replication configuration file to point to it. Note that if --upstream-node-id is not explicitly provided, - &repmgr; will set the standby's recovery.conf to + &repmgr; will set the standby's replication configuration to point to the primary node. @@ -392,7 +392,7 @@ description = "Main cluster" does not yet exist. In this case you can clone from the primary (or another upstream node); provide the parameter --upstream-conninfo to explicitly set the upstream's primary_conninfo string - in recovery.conf. + in the replication configuration. @@ -491,12 +491,12 @@ description = "Main cluster" - If, for whatever reason, you wish to include the password in recovery.conf, + If, for whatever reason, you wish to include the password in the replication configuration file, 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 + string in the replication configuration. Note that PGPASSWORD + will need to be set during any action which causes the replication configuration file to be rewritten, e.g. . @@ -508,7 +508,7 @@ description = "Main cluster" 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 + replication connections and generating the replication configuration. 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 . diff --git a/doc/quickstart.xml b/doc/quickstart.xml index b7c5d056..08c77474 100644 --- a/doc/quickstart.xml +++ b/doc/quickstart.xml @@ -405,9 +405,10 @@ This has cloned the PostgreSQL data directory files from the primary node1 - using PostgreSQL's pg_basebackup utility. A recovery.conf - file containing the correct parameters to start streaming from this primary server will be created - automatically. + using PostgreSQL's pg_basebackup utility. Replication configuration + containing the correct parameters to start streaming from this primary server will be + automatically appended to postgresql.auto.conf. (In PostgreSQL 11 + and earlier the file recovery.conf will be created). @@ -481,9 +482,10 @@ sender_port | 5432 conninfo | user=repmgr dbname=replication host=node1 application_name=node2 - Note that the conninfo value is that generated in recovery.conf - and will differ slightly from the primary's conninfo as set in repmgr.conf - - among others it will contain the connecting node's name as application_name. + Note that the conninfo value is that generated in postgresql.auto.conf + (PostgreSQL 11 and earlier: recovery.conf) and will differ slightly from the primary's + conninfo as set in repmgr.conf - among others it will contain the + connecting node's name as application_name.