diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/config.sgml | 13 | ||||
| -rw-r--r-- | doc/src/sgml/high-availability.sgml | 39 |
2 files changed, 50 insertions, 2 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 0d8624af718..5549b7dce62 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2521,7 +2521,7 @@ include_dir 'conf.d' <variablelist> <varlistentry id="guc-archive-mode" xreflabel="archive_mode"> - <term><varname>archive_mode</varname> (<type>boolean</type>) + <term><varname>archive_mode</varname> (<type>enum</type>) <indexterm> <primary><varname>archive_mode</> configuration parameter</primary> </indexterm> @@ -2530,7 +2530,16 @@ include_dir 'conf.d' <para> When <varname>archive_mode</> is enabled, completed WAL segments are sent to archive storage by setting - <xref linkend="guc-archive-command">. + <xref linkend="guc-archive-command">. In addition to <literal>off</>, + to disable, there are two modes: <literal>on</>, and + <literal>always</>. During normal operation, there is no + difference between the two modes, but when set to <literal>always</> + the WAL archiver is enabled also during archive recovery or standby + mode. In <literal>always</> mode, all files restored from the archive + or streamed with streaming replication will be archived (again). See + <xref linkend="continuous-archiving-in-standby"> for details. + </para> + <para> <varname>archive_mode</> and <varname>archive_command</> are separate variables so that <varname>archive_command</> can be changed without leaving archiving mode. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index a17f55545c9..46518262cd6 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1220,6 +1220,45 @@ primary_slot_name = 'node_a_slot' </sect3> </sect2> + + <sect2 id="continuous-archiving-in-standby"> + <title>Continuous archiving in standby</title> + + <indexterm> + <primary>continuous archiving</primary> + <secondary>in standby</secondary> + </indexterm> + + <para> + When continuous WAL archiving is used in a standby, there are two + different scenarios: the WAL archive can be shared between the primary + and the standby, or the standby can have its own WAL archive. When + the standby has its own WAL archive, set <varname>archive_mode</varname> + to <literal>always</literal>, and the standby will call the archive + command for every WAL segment it receives, whether it's by restoring + from the archive or by streaming replication. The shared archive can + be handled similarly, but the archive_command must test if the file + being archived exists already, and if the existing file has identical + contents. This requires more care in the archive_command, as it must + be careful to not overwrite an existing file with different contents, + but return success if the exactly same file is archived twice. And + all that must be done free of race conditions, if two servers attempt + to archive the same file at the same time. + </para> + + </para> + If <varname>archive_mode</varname> is set to <literal>on</>, the + archiver is not enabled during recovery or standby mode. If the standby + server is promoted, it will start archiving after the promotion, but + will not archive any WAL it did not generate itself. To get a complete + series of WAL files in the archive, you must ensure that all WAL is + archived, before it reaches the standby. This is inherently true with + file-based log shipping, as the standby can only restore files that + are found in the archive, but not if streaming replication is enabled. + When a server is not in recovery mode, there is no difference between + <literal>on</literal> and <literal>always</literal> modes. + </para> + </sect2> </sect1> <sect1 id="warm-standby-failover"> |