database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-11 20:28:21 +03:00
Code Activity

Add new replication mode synchronous_commit = 'remote_apply'.

Browse Source 
In this mode, the master waits for the transaction to be applied on
the remote side, not just written to disk.  That means that you can
count on a transaction started on the standby to see all commits
previously acknowledged by the master.

To make this work, the standby sends a reply after replaying each
commit record generated with synchronous_commit >= 'remote_apply'.
This introduces a small inefficiency: the extra replies will be sent
even by standbys that aren't the current synchronous standby.  But
previously-existing synchronous_commit levels make no attempt at all
to optimize which replies are sent based on what the primary cares
about, so this is no worse, and at least avoids any extra replies for
people not using the feature at all.

Thomas Munro, reviewed by Michael Paquier and by me.  Some additional
tweaks by me.
This commit is contained in:
Robert Haas
2016-03-29 21:16:12 -04:00
parent a898b409f6
commit 314cbfc5da
16 changed files with 208 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
doc/src/sgml/config.sgml
View File

@ -2143,8 +2143,8 @@ include_dir 'conf.d'
Specifies whether transaction commit will wait for WAL records
to be written to disk before the command returns a <quote>success</>
indication to the client. Valid values are <literal>on</>,
<literal>remote_write</>, <literal>local</>, and <literal>off</>.
The default, and safe, setting
<literal>remote_write</>, <literal>remote_apply</>, <literal>local</>,
and <literal>off</>. The default, and safe, setting
is <literal>on</>. When <literal>off</>, there can be a delay between
when success is reported to the client and when the transaction is
really guaranteed to be safe against a server crash. (The maximum
@ -2169,6 +2169,10 @@ include_dir 'conf.d'
the commit record of the transaction and flushed it to disk. This
ensures the transaction will not be lost unless both primary and
standby suffer corruption of their database storage.
When set to <literal>remote_apply</>, commits will wait until a reply
from the current synchronous standby indicates it has received the
commit record of the transaction and applied it, so that it has become
visible to queries.
When set to <literal>remote_write</>, commits will wait
until a reply from the current synchronous standby indicates it has
received the commit record of the transaction and written it out to
@ -2186,9 +2190,9 @@ include_dir 'conf.d'
setting <literal>local</> is available for transactions that
wish to wait for local flush to disk, but not synchronous replication.
If <varname>synchronous_standby_names</> is not set, the settings
<literal>on</>, <literal>remote_write</> and <literal>local</> all
provide the same synchronization level: transaction commits only wait
for local flush to disk.
<literal>on</>, <literal>remote_apply</>, <literal>remote_write</>
and <literal>local</> all provide the same synchronization level:
transaction commits only wait for local flush to disk.
</para>
<para>
This parameter can be changed at any time; the behavior for any

18
doc/src/sgml/high-availability.sgml
View File

@ -1081,6 +1081,9 @@ primary_slot_name = 'node_a_slot'
WAL record is then sent to the standby. The standby sends reply
messages each time a new batch of WAL data is written to disk, unless
<varname>wal_receiver_status_interval</> is set to zero on the standby.
In the case that <varname>synchronous_commit</> is set to
<literal>remote_apply</>, the standby sends reply messages when the commit
record is replayed, making the transaction visible.
If the standby is the first matching standby, as specified in
<varname>synchronous_standby_names</> on the primary, the reply
messages from that standby will be used to wake users waiting for
@ -1106,6 +1109,14 @@ primary_slot_name = 'node_a_slot'
the database of the primary gets corrupted at the same time.
</para>
<para>
Setting <varname>synchronous_commit</> to <literal>remote_apply</> will
cause each commit to wait until the current synchronous standby reports
that it has replayed the transaction, making it visible to user queries.
In simple cases, this allows for load balancing with causal consistency
on a single hot standby.
</para>
<para>
Users will stop waiting if a fast shutdown is requested. However, as
when using asynchronous replication, the server will not fully
@ -1160,9 +1171,10 @@ primary_slot_name = 'node_a_slot'
<title>Planning for High Availability</title>
<para>
Commits made when <varname>synchronous_commit</> is set to <literal>on</>
or <literal>remote_write</> will wait until the synchronous standby responds. The response
may never occur if the last, or only, standby should crash.
Commits made when <varname>synchronous_commit</> is set to <literal>on</>,
<literal>remote_apply</> or <literal>remote_write</> will wait until the
synchronous standby responds. The response may never occur if the last, or
only, standby should crash.
</para>
<para>