From 314cbfc5da988eff8998655158f84c9815ecfbcd Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Tue, 29 Mar 2016 21:16:12 -0400 Subject: Add new replication mode synchronous_commit = 'remote_apply'. 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. --- doc/src/sgml/config.sgml | 14 +++++++++----- doc/src/sgml/high-availability.sgml | 18 +++++++++++++++--- 2 files changed, 24 insertions(+), 8 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index d48a13f33a8..1c4f7965f6e 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -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 success indication to the client. Valid values are on, - remote_write, local, and off. - The default, and safe, setting + remote_write, remote_apply, local, + and off. The default, and safe, setting is on. When 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 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 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 local is available for transactions that wish to wait for local flush to disk, but not synchronous replication. If synchronous_standby_names is not set, the settings - on, remote_write and local all - provide the same synchronization level: transaction commits only wait - for local flush to disk. + on, remote_apply, remote_write + and local all provide the same synchronization level: + transaction commits only wait for local flush to disk. This parameter can be changed at any time; the behavior for any diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 19d613e3b1a..d32ceb12b3e 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -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 wal_receiver_status_interval is set to zero on the standby. + In the case that synchronous_commit is set to + 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 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. + + Setting synchronous_commit to 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. + + 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' Planning for High Availability - Commits made when synchronous_commit is set to on - or 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 synchronous_commit is set to on, + remote_apply or remote_write will wait until the + synchronous standby responds. The response may never occur if the last, or + only, standby should crash. -- cgit v1.2.3