@@ -1844,9 +1844,9 @@ SET ENABLE_SEQSCAN TO OFF;
1844
1844
<varname>archive_mode</> and <varname>archive_command</> are
1845
1845
separate variables so that <varname>archive_command</> can be
1846
1846
changed without leaving archiving mode.
1847
- This parameter can only be set at server start. <varname>wal_level</>
1848
- must be set to <literal>archive </> or <literal>hot_standby</> to
1849
- enable <varname>archive_mode </>.
1847
+ This parameter can only be set at server start.
1848
+ <varname>archive_mode </> cannot be enabled when
1849
+ <varname>wal_level</> is set to <literal>minimal </>.
1850
1850
</para>
1851
1851
</listitem>
1852
1852
</varlistentry>
@@ -1911,7 +1911,10 @@ SET ENABLE_SEQSCAN TO OFF;
1911
1911
files. Therefore, it is unwise to use a very short
1912
1912
<varname>archive_timeout</> — it will bloat your archive
1913
1913
storage. <varname>archive_timeout</> settings of a minute or so are
1914
- usually reasonable. This parameter can only be set in the
1914
+ usually reasonable. You should consider using streaming replication,
1915
+ instead of archiving, if you want data to be copied off the master
1916
+ server more quickly than that.
1917
+ This parameter can only be set in the
1915
1918
<filename>postgresql.conf</> file or on the server command line.
1916
1919
</para>
1917
1920
</listitem>
@@ -1920,14 +1923,32 @@ SET ENABLE_SEQSCAN TO OFF;
1920
1923
</variablelist>
1921
1924
</sect2>
1922
1925
1923
- <sect2 id="runtime-config-replication">
1924
- <title>Streaming Replication</title>
1926
+ </sect1>
1927
+
1928
+ <sect1 id="runtime-config-replication">
1929
+ <title>Replication</title>
1930
+
1931
+ <para>
1932
+ These settings control the behavior of the built-in
1933
+ <firstterm>streaming replication</> feature (see
1934
+ <xref linkend="streaming-replication">).
1935
+ Some parameters must be set on the master server, while others must be
1936
+ set on the standby server(s) that will receive replication data.
1937
+ </para>
1938
+
1939
+ <sect2 id="runtime-config-replication-master">
1940
+ <title>Master Server</title>
1925
1941
1926
1942
<para>
1927
- These settings control the behavior of the built-in
1928
- <firstterm>streaming replication</> feature.
1929
- These parameters would be set on the primary server that is
1943
+ These parameters can be set on the primary server that is
1930
1944
to send replication data to one or more standby servers.
1945
+ Note that in addition to these parameters,
1946
+ <xref linkend="guc-wal-level"> must be set appropriately on the master
1947
+ server, and you will typically want to enable WAL archiving as
1948
+ well (see <xref linkend="runtime-config-wal-archiving">).
1949
+ The values of these parameters on standby servers are irrelevant,
1950
+ although you may wish to set them there in preparation for the
1951
+ possibility of a standby becoming the master.
1931
1952
</para>
1932
1953
1933
1954
<variablelist>
@@ -1995,7 +2016,7 @@ SET ENABLE_SEQSCAN TO OFF;
1995
2016
<filename>pg_xlog</>; the system might need to retain more segments
1996
2017
for WAL archival or to recover from a checkpoint. If
1997
2018
<varname>wal_keep_segments</> is zero (the default), the system
1998
- doesn't keep any extra segments for standby purposes, and the number
2019
+ doesn't keep any extra segments for standby purposes, so the number
1999
2020
of old WAL segments available to standby servers is a function of
2000
2021
the location of the previous checkpoint and status of WAL
2001
2022
archiving. This parameter has no effect on restartpoints.
@@ -2057,50 +2078,45 @@ SET ENABLE_SEQSCAN TO OFF;
2057
2078
</para>
2058
2079
</listitem>
2059
2080
</varlistentry>
2060
- </variablelist>
2061
- </sect2>
2062
-
2063
- <sect2 id="runtime-config-sync-rep">
2064
- <title>Synchronous Replication</title>
2065
-
2066
- <para>
2067
- These settings control the behavior of the built-in
2068
- <firstterm>synchronous replication</> feature.
2069
- These parameters would be set on the primary server that is
2070
- to send replication data to one or more standby servers.
2071
- </para>
2072
2081
2073
- <variablelist>
2074
2082
<varlistentry id="guc-synchronous-standby-names" xreflabel="synchronous_standby_names">
2075
2083
<term><varname>synchronous_standby_names</varname> (<type>string</type>)</term>
2076
2084
<indexterm>
2077
2085
<primary><varname>synchronous_standby_names</> configuration parameter</primary>
2078
2086
</indexterm>
2079
2087
<listitem>
2080
2088
<para>
2081
- Specifies a priority ordered list of standby names that can offer
2082
- synchronous replication. At any one time there will be at most one
2083
- synchronous standby that will wake sleeping users following commit.
2084
- The synchronous standby will be the first named standby that is
2085
- both currently connected and streaming in real-time to the standby
2086
- (as shown by a state of <literal>STREAMING</literal>). Other standby servers
2087
- with listed later will become potential synchronous standbys.
2088
- If the current synchronous standby disconnects for whatever reason
2089
- it will be replaced immediately with the next highest priority standby.
2089
+ Specifies a comma-separated list of standby names that can support
2090
+ <firstterm>synchronous replication</>, as described in
2091
+ <xref linkend="synchronous-replication">.
2092
+ At any one time there will be at most one active synchronous standby;
2093
+ transactions waiting for commit will be allowed to proceed after
2094
+ this standby server confirms receipt of their data.
2095
+ The synchronous standby will be the first standby named in this list
2096
+ that is both currently connected and streaming data in real-time
2097
+ (as shown by a state of <literal>STREAMING</literal> in the
2098
+ <link linkend="monitoring-stats-views-table">
2099
+ <literal>pg_stat_replication</></link> view).
2100
+ Other standby servers appearing later in this list represent potential
2101
+ synchronous standbys.
2102
+ If the current synchronous standby disconnects for whatever reason,
2103
+ it will be replaced immediately with the next-highest-priority standby.
2090
2104
Specifying more than one standby name can allow very high availability.
2091
2105
</para>
2092
2106
<para>
2093
- The standby name is currently taken as the <varname>application_name</> setting of the
2094
- standby, as set in the <varname>primary_conninfo</> on the standby. Names are
2095
- not enforced for uniqueness. In case of duplicates one of the standbys
2096
- will be chosen to be the synchronous standby, though exactly which
2097
- one is indeterminate.
2098
- The special entry <literal>*</> matches any application_name, including
2099
- the default application name of <literal>walreceiver</>.
2107
+ The name of a standby server for this purpose is the
2108
+ <varname>application_name</> setting of the standby, as set in the
2109
+ <varname>primary_conninfo</> of the standby's walreceiver. There is
2110
+ no mechanism to enforce uniqueness. In case of duplicates one of the
2111
+ matching standbys will be chosen to be the synchronous standby, though
2112
+ exactly which one is indeterminate.
2113
+ The special entry <literal>*</> matches any
2114
+ <varname>application_name</>, including the default application name
2115
+ of <literal>walreceiver</>.
2100
2116
</para>
2101
2117
<para>
2102
- If no synchronous standby names are specified, then synchronous
2103
- replication is not enabled and transaction commit will never wait for
2118
+ If no synchronous standby names are specified here , then synchronous
2119
+ replication is not enabled and transaction commits will not wait for
2104
2120
replication. This is the default configuration. Even when
2105
2121
synchronous replication is enabled, individual transactions can be
2106
2122
configured not to wait for replication by setting the
@@ -2117,12 +2133,13 @@ SET ENABLE_SEQSCAN TO OFF;
2117
2133
</variablelist>
2118
2134
</sect2>
2119
2135
2120
- <sect2 id="runtime-config-standby">
2121
- <title>Standby Servers</title>
2136
+ <sect2 id="runtime-config-replication- standby">
2137
+ <title>Standby Servers</title>
2122
2138
2123
2139
<para>
2124
2140
These settings control the behavior of a standby server that is
2125
- to receive replication data.
2141
+ to receive replication data. Their values on the master server
2142
+ are irrelevant.
2126
2143
</para>
2127
2144
2128
2145
<variablelist>
@@ -2213,12 +2230,14 @@ SET ENABLE_SEQSCAN TO OFF;
2213
2230
<para>
2214
2231
Specifies the minimum frequency for the WAL receiver
2215
2232
process on the standby to send information about replication progress
2216
- to the primary, where they can be seen using the
2217
- <literal>pg_stat_replication</literal> view. The standby will report
2233
+ to the primary, where it can be seen using the
2234
+ <link linkend="monitoring-stats-views-table">
2235
+ <literal>pg_stat_replication</></link> view. The standby will report
2218
2236
the last transaction log position it has written, the last position it
2219
- has flushed to disk, and the last position it has applied. The parameter
2237
+ has flushed to disk, and the last position it has applied.
2238
+ This parameter's
2220
2239
value is the maximum interval, in seconds, between reports. Updates are
2221
- sent each time the write or flush positions changed , or at least as
2240
+ sent each time the write or flush positions change , or at least as
2222
2241
often as specified by this parameter. Thus, the apply position may
2223
2242
lag slightly behind the true position. Setting this parameter to zero
2224
2243
disables status updates completely. This parameter can only be set in
0 commit comments