From 443b4821f1649bc617c5ce1f6f3ffc65842a8930 Mon Sep 17 00:00:00 2001 From: Simon Riggs Date: Tue, 24 Jan 2012 20:22:37 +0000 Subject: Add new replication mode synchronous_commit = 'write'. Replication occurs only to memory on standby, not to disk, so provides additional performance if user wishes to reduce durability level slightly. Adds concept of multiple independent sync rep queues. Fujii Masao and Simon Riggs --- doc/src/sgml/config.sgml | 18 +++++++++++++----- doc/src/sgml/high-availability.sgml | 16 +++++++++++++--- 2 files changed, 26 insertions(+), 8 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index e55b5035e26..309b6a54615 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1560,7 +1560,7 @@ SET ENABLE_SEQSCAN TO OFF; 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, + indication to the client. Valid values are on, write, local, and off. The default, and safe, value is on. When off, there can be a delay between when success is reported to the client and when the transaction is @@ -1580,11 +1580,19 @@ SET ENABLE_SEQSCAN TO OFF; If is set, this parameter also controls whether or not transaction commit will wait for the transaction's WAL records to be flushed to disk and replicated - to the standby server. The commit wait will last until a reply from - the current synchronous standby indicates it has written the commit - record of the transaction to durable storage. If synchronous + to the standby server. When write, the commit wait will + last until a reply from the current synchronous standby indicates + it has received the commit record of the transaction to memory. + Normally this causes no data loss at the time of failover. However, + if both primary and standby crash, and the database cluster of + the primary gets corrupted, recent committed transactions might + be lost. When on, the commit wait will last until a reply + from the current synchronous standby indicates it has flushed + the commit record of the transaction to durable storage. This + avoids any data loss unless the database cluster of both primary and + standby gets corrupted simultaneously. If synchronous replication is in use, it will normally be sensible either to wait - both for WAL records to reach both the local and remote disks, or + for both local flush and replication of WAL records, or to allow the transaction to commit asynchronously. However, the special value local is available for transactions that wish to wait for local flush to disk, but not synchronous replication. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index c5db6ef01f8..ed34dac023d 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1010,6 +1010,16 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' standby servers using cascaded replication. + + Setting synchronous_commit to write will + cause each commit to wait for confirmation that the standby has received + the commit record to memory. This provides a lower level of durability + than on does. However, it's a practically useful setting + because it can decrease the response time for the transaction, and causes + no data loss unless both the primary and the standby crashes and + the database of the primary gets corrupted at the same time. + + Users will stop waiting if a fast shutdown is requested. However, as when using asynchronous replication, the server will does not fully @@ -1065,13 +1075,13 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' Commits made when synchronous_commit is set to on - will wait until the sync standby responds. The response may never occur - if the last, or only, standby should crash. + or write will wait until the synchronous standby responds. The response + may never occur if the last, or only, standby should crash. The best solution for avoiding data loss is to ensure you don't lose - your last remaining sync standby. This can be achieved by naming multiple + your last remaining synchronous standby. This can be achieved by naming multiple potential synchronous standbys using synchronous_standby_names. The first named standby will be used as the synchronous standby. Standbys listed after this will take over the role of synchronous standby if the -- cgit v1.2.3