diff --git a/doc/appendix-faq.sgml b/doc/appendix-faq.sgml index cf7256a6..e6320575 100644 --- a/doc/appendix-faq.sgml +++ b/doc/appendix-faq.sgml @@ -105,6 +105,7 @@ standby to have been cloned using &repmgr;. + Can I use a standby not cloned by &repmgr; as a &repmgr; node? @@ -118,6 +119,13 @@ + + What does &repmgr; write in <filename>recovery.conf</filename>, and what options can be set there? + + See section Customising recovery.conf. + + + How can a failed primary be re-added as a standby? @@ -126,19 +134,23 @@ needs to be re-registered as a standby. - In PostgreSQL 9.5 and later, it's possible to use pg_rewind - to re-synchronise the existing data directory, which will usually be much + It's possible to use pg_rewind to re-synchronise the existing data + directory, which will usually be much faster than re-cloning the server. However pg_rewind can only be used if PostgreSQL either has wal_log_hints enabled, or data checksums were enabled when the cluster was initialized. - &repmgr; provides the command repmgr node rejoin which can - optionally execute pg_rewind; see the - documentation for details. + Note that pg_rewind is available as part of the core PostgreSQL + distribution from PostgreSQL 9.5, and as a third-party utility for PostgreSQL 9.3 and 9.4. - If pg_rewind cannot be used, then the data directory will have + &repmgr; provides the command repmgr node rejoin which can + optionally execute pg_rewind; see the + documentation for details, in particular the section . + + + If pg_rewind cannot be used, then the data directory will need to be re-cloned from scratch.