database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Add new replication mode synchronous_commit = 'write'.

Browse Source 
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
This commit is contained in:
Simon Riggs
2012-01-24 20:22:37 +00:00
parent 89dda5f297
commit 443b4821f1
8 changed files with 124 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1560,7 +1560,7 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
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</>,
indication to the client. Valid values are <literal>on</>, <literal>write</>,
<literal>local</>, and <literal>off</>. The default, and safe, value
is <literal>on</>. When <literal>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 <xref linkend="guc-synchronous-standby-names"> 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 <literal>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 <literal>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 <literal>local</> is available for transactions that
wish to wait for local flush to disk, but not synchronous replication.

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

@ -1010,6 +1010,16 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
standby servers using cascaded replication.
</para>
<para>
Setting <varname>synchronous_commit</> to <literal>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 <literal>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.
</para>
<para>
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'
<para>
Commits made when <varname>synchronous_commit</> is set to <literal>on</>
will wait until the sync standby responds. The response may never occur
if the last, or only, standby should crash.
or <literal>write</> will wait until the synchronous standby responds. The response
may never occur if the last, or only, standby should crash.
</para>
<para>
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 <varname>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