diff options
| author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2011-03-07 21:02:40 +0200 |
|---|---|---|
| committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2011-03-07 21:14:47 +0200 |
| commit | 1a4ab9ec23f0635a4c15b069df60b545814650e9 (patch) | |
| tree | 6d09c873cf835ea5962c0fd48995b29666f301fd /doc/src | |
| parent | bcf85e3f44a518eb7bb759541189efb6726fe9bc (diff) | |
| download | postgresql-1a4ab9ec23f0635a4c15b069df60b545814650e9.tar.gz postgresql-1a4ab9ec23f0635a4c15b069df60b545814650e9.zip | |
If recovery_target_timeline is set to 'latest' and standby mode is enabled,
periodically rescan the archive for new timelines, while waiting for new WAL
segments to arrive. This allows you to set up a standby server that follows
the TLI change if another standby server is promoted to master. Before this,
you had to restart the standby server to make it notice the new timeline.
This patch only scans the archive for TLI changes, it won't follow a TLI
change in streaming replication. That is much needed too, but it would be a
much bigger patch than I dare to sneak in this late in the release cycle.
There was discussion on improving the sanity checking of the WAL segments so
that the system would notice more reliably if the new timeline isn't an
ancestor of the current one, but that is not included in this patch.
Reviewed by Fujii Masao.
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/high-availability.sgml | 5 | ||||
| -rw-r--r-- | doc/src/sgml/recovery-config.sgml | 4 |
2 files changed, 7 insertions, 2 deletions
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index e33d3151375..b97167fc50b 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -660,7 +660,10 @@ protocol to make nodes agree on a serializable transactional order. command file <filename>recovery.conf</> in the standby's cluster data directory, and turn on <varname>standby_mode</>. Set <varname>restore_command</> to a simple command to copy files from - the WAL archive. + the WAL archive. If you plan to have multiple standby servers for high + availability purposes, set <varname>recovery_target_timeline</> to + <literal>latest</>, to make the standby server follow the timeline change + that occurs at failover to another standby. </para> <note> diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml index 602fbe2c76e..e9e95acb8dc 100644 --- a/doc/src/sgml/recovery-config.sgml +++ b/doc/src/sgml/recovery-config.sgml @@ -240,7 +240,9 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows <para> Specifies recovering into a particular timeline. The default is to recover along the same timeline that was current when the - base backup was taken. You only need to set this parameter + base backup was taken. Setting this to <literal>latest</> recovers + to the latest timeline found in the archive, which is useful in + a standby server. Other than that you only need to set this parameter in complex re-recovery situations, where you need to return to a state that itself was reached after a point-in-time recovery. See <xref linkend="backup-timelines"> for discussion. |