Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commita8a8a3e

Browse files
Efficient transaction-controlled synchronous replication.
If a standby is broadcasting reply messages and we have namedone or more standbys in synchronous_standby_names then allowusers who set synchronous_replication to wait for commit, whichthen provides strict data integrity guarantees. Design avoidssending and receiving transaction state information so minimisesbookkeeping overheads. We synchronize with the highest prioritystandby that is connected and ready to synchronize. Other standbyscan be defined to takeover in case of standby failure.This version has very strict behaviour; more relaxed optionsmay be added at a later date.Simon Riggs and Fujii Masao, with reviews by Yeb Havinga, JaimeCasanova, Heikki Linnakangas and Robert Haas, plus the assistanceof many other design reviewers.
1 parent149b267 commita8a8a3e

File tree

21 files changed

+507
-22
lines changed

21 files changed

+507
-22
lines changed

‎doc/src/sgml/config.sgml‎

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2018,6 +2018,92 @@ SET ENABLE_SEQSCAN TO OFF;
20182018
</variablelist>
20192019
</sect2>
20202020

2021+
<sect2 id="runtime-config-sync-rep">
2022+
<title>Synchronous Replication</title>
2023+
2024+
<para>
2025+
These settings control the behavior of the built-in
2026+
<firstterm>synchronous replication</> feature.
2027+
These parameters would be set on the primary server that is
2028+
to send replication data to one or more standby servers.
2029+
</para>
2030+
2031+
<variablelist>
2032+
<varlistentry id="guc-synchronous-replication" xreflabel="synchronous_replication">
2033+
<term><varname>synchronous_replication</varname> (<type>boolean</type>)</term>
2034+
<indexterm>
2035+
<primary><varname>synchronous_replication</> configuration parameter</primary>
2036+
</indexterm>
2037+
<listitem>
2038+
<para>
2039+
Specifies whether transaction commit will wait for WAL records
2040+
to be replicated before the command returns a <quote>success</>
2041+
indication to the client. The default setting is <literal>off</>.
2042+
When <literal>on</>, there will be a delay while the client waits
2043+
for confirmation of successful replication. That delay will
2044+
increase depending upon the physical distance and network activity
2045+
between primary and standby. The commit wait will last until a
2046+
reply from the current synchronous standby indicates it has received
2047+
the commit record of the transaction. Synchronous standbys must
2048+
already have been defined (see <xref linkend="guc-sync-standby-names">).
2049+
</para>
2050+
<para>
2051+
This parameter can be changed at any time; the
2052+
behavior for any one transaction is determined by the setting in
2053+
effect when it commits. It is therefore possible, and useful, to have
2054+
some transactions replicate synchronously and others asynchronously.
2055+
For example, to make a single multistatement transaction commit
2056+
asynchronously when the default is synchronous replication, issue
2057+
<command>SET LOCAL synchronous_replication TO OFF</> within the
2058+
transaction.
2059+
</para>
2060+
</listitem>
2061+
</varlistentry>
2062+
2063+
<varlistentry id="guc-sync-standby-names" xreflabel="synchronous_standby_names">
2064+
<term><varname>synchronous_standby_names</varname> (<type>integer</type>)</term>
2065+
<indexterm>
2066+
<primary><varname>synchronous_standby_names</> configuration parameter</primary>
2067+
</indexterm>
2068+
<listitem>
2069+
<para>
2070+
Specifies a priority ordered list of standby names that can offer
2071+
synchronous replication. At any one time there will be just one
2072+
synchronous standby that will wake sleeping users following commit.
2073+
The synchronous standby will be the first named standby that is
2074+
both currently connected and streaming in real-time to the standby
2075+
(as shown by a state of "STREAMING"). Other standby servers
2076+
with listed later will become potential synchronous standbys.
2077+
If the current synchronous standby disconnects for whatever reason
2078+
it will be replaced immediately with the next highest priority standby.
2079+
Specifying more than one standby name can allow very high availability.
2080+
</para>
2081+
<para>
2082+
The standby name is currently taken as the application_name of the
2083+
standby, as set in the primary_conninfo on the standby. Names are
2084+
not enforced for uniqueness. In case of duplicates one of the standbys
2085+
will be chosen to be the synchronous standby, though exactly which
2086+
one is indeterminate.
2087+
</para>
2088+
<para>
2089+
No value is set by default.
2090+
The special entry <literal>*</> matches any application_name, including
2091+
the default application name of <literal>walreceiver</>.
2092+
</para>
2093+
<para>
2094+
If a standby is removed from the list of servers then it will stop
2095+
being the synchronous standby, allowing another to take it's place.
2096+
If the list is empty, synchronous replication will not be
2097+
possible, whatever the setting of <varname>synchronous_replication</>,
2098+
however, already waiting commits will continue to wait.
2099+
Standbys may also be added to the list without restarting the server.
2100+
</para>
2101+
</listitem>
2102+
</varlistentry>
2103+
2104+
</variablelist>
2105+
</sect2>
2106+
20212107
<sect2 id="runtime-config-standby">
20222108
<title>Standby Servers</title>
20232109

‎doc/src/sgml/high-availability.sgml‎

Lines changed: 203 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -875,6 +875,209 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
875875
</sect3>
876876

877877
</sect2>
878+
<sect2 id="synchronous-replication">
879+
<title>Synchronous Replication</title>
880+
881+
<indexterm zone="high-availability">
882+
<primary>Synchronous Replication</primary>
883+
</indexterm>
884+
885+
<para>
886+
<productname>PostgreSQL</> streaming replication is asynchronous by
887+
default. If the primary server
888+
crashes then some transactions that were committed may not have been
889+
replicated to the standby server, causing data loss. The amount
890+
of data loss is proportional to the replication delay at the time of
891+
failover.
892+
</para>
893+
894+
<para>
895+
Synchronous replication offers the ability to confirm that all changes
896+
made by a transaction have been transferred to one synchronous standby
897+
server. This extends the standard level of durability
898+
offered by a transaction commit. This level of protection is referred
899+
to as 2-safe replication in computer science theory.
900+
</para>
901+
902+
<para>
903+
When requesting synchronous replication, each commit of a
904+
write transaction will wait until confirmation is
905+
received that the commit has been written to the transaction log on disk
906+
of both the primary and standby server. The only possibility that data
907+
can be lost is if both the primary and the standby suffer crashes at the
908+
same time. This can provide a much higher level of durability, though only
909+
if the sysadmin is cautious about the placement and management of the two
910+
servers. Waiting for confirmation increases the user's confidence that the
911+
changes will not be lost in the event of server crashes but it also
912+
necessarily increases the response time for the requesting transaction.
913+
The minimum wait time is the roundtrip time between primary to standby.
914+
</para>
915+
916+
<para>
917+
Read only transactions and transaction rollbacks need not wait for
918+
replies from standby servers. Subtransaction commits do not wait for
919+
responses from standby servers, only top-level commits. Long
920+
running actions such as data loading or index building do not wait
921+
until the very final commit message. All two-phase commit actions
922+
require commit waits, including both prepare and commit.
923+
</para>
924+
925+
<sect3 id="synchronous-replication-config">
926+
<title>Basic Configuration</title>
927+
928+
<para>
929+
All parameters have useful default values, so we can enable
930+
synchronous replication easily just by setting this on the primary
931+
932+
<programlisting>
933+
synchronous_replication = on
934+
</programlisting>
935+
936+
When <varname>synchronous_replication</> is set, a commit will wait
937+
for confirmation that the standby has received the commit record,
938+
even if that takes a very long time.
939+
<varname>synchronous_replication</> can be set by individual
940+
users, so can be configured in the configuration file, for particular
941+
users or databases, or dynamically by applications programs.
942+
</para>
943+
944+
<para>
945+
After a commit record has been written to disk on the primary the
946+
WAL record is then sent to the standby. The standby sends reply
947+
messages each time a new batch of WAL data is received, unless
948+
<varname>wal_receiver_status_interval</> is set to zero on the standby.
949+
If the standby is the first matching standby, as specified in
950+
<varname>synchronous_standby_names</> on the primary, the reply
951+
messages from that standby will be used to wake users waiting for
952+
confirmation the commit record has been received. These parameters
953+
allow the administrator to specify which standby servers should be
954+
synchronous standbys. Note that the configuration of synchronous
955+
replication is mainly on the master.
956+
</para>
957+
958+
<para>
959+
Users will stop waiting if a fast shutdown is requested, though the
960+
server does not fully shutdown until all outstanding WAL records are
961+
transferred to standby servers.
962+
</para>
963+
964+
<para>
965+
Note also that <varname>synchronous_commit</> is used when the user
966+
specifies <varname>synchronous_replication</>, overriding even an
967+
explicit setting of <varname>synchronous_commit</> to <literal>off</>.
968+
This is because we must write WAL to disk on primary before we replicate
969+
to ensure the standby never gets ahead of the primary.
970+
</para>
971+
972+
</sect3>
973+
974+
<sect3 id="synchronous-replication-performance">
975+
<title>Planning for Performance</title>
976+
977+
<para>
978+
Synchronous replication usually requires carefully planned and placed
979+
standby servers to ensure applications perform acceptably. Waiting
980+
doesn't utilise system resources, but transaction locks continue to be
981+
held until the transfer is confirmed. As a result, incautious use of
982+
synchronous replication will reduce performance for database
983+
applications because of increased response times and higher contention.
984+
</para>
985+
986+
<para>
987+
<productname>PostgreSQL</> allows the application developer
988+
to specify the durability level required via replication. This can be
989+
specified for the system overall, though it can also be specified for
990+
specific users or connections, or even individual transactions.
991+
</para>
992+
993+
<para>
994+
For example, an application workload might consist of:
995+
10% of changes are important customer details, while
996+
90% of changes are less important data that the business can more
997+
easily survive if it is lost, such as chat messages between users.
998+
</para>
999+
1000+
<para>
1001+
With synchronous replication options specified at the application level
1002+
(on the primary) we can offer sync rep for the most important changes,
1003+
without slowing down the bulk of the total workload. Application level
1004+
options are an important and practical tool for allowing the benefits of
1005+
synchronous replication for high performance applications.
1006+
</para>
1007+
1008+
<para>
1009+
You should consider that the network bandwidth must be higher than
1010+
the rate of generation of WAL data.
1011+
10% of changes are important customer details, while
1012+
90% of changes are less important data that the business can more
1013+
easily survive if it is lost, such as chat messages between users.
1014+
</para>
1015+
1016+
</sect3>
1017+
1018+
<sect3 id="synchronous-replication-ha">
1019+
<title>Planning for High Availability</title>
1020+
1021+
<para>
1022+
Commits made when synchronous_replication is set will wait until at
1023+
the sync standby responds. The response may never occur if the last,
1024+
or only, standby should crash.
1025+
</para>
1026+
1027+
<para>
1028+
The best solution for avoiding data loss is to ensure you don't lose
1029+
your last remaining sync standby. This can be achieved by naming multiple
1030+
potential synchronous standbys using <varname>synchronous_standby_names</>.
1031+
The first named standby will be used as the synchronous standby. Standbys
1032+
listed after this will takeover the role of synchronous standby if the
1033+
first one should fail.
1034+
</para>
1035+
1036+
<para>
1037+
When a standby first attaches to the primary, it will not yet be properly
1038+
synchronized. This is described as <literal>CATCHUP</> mode. Once
1039+
the lag between standby and primary reaches zero for the first time
1040+
we move to real-time <literal>STREAMING</> state.
1041+
The catch-up duration may be long immediately after the standby has
1042+
been created. If the standby is shutdown, then the catch-up period
1043+
will increase according to the length of time the standby has been down.
1044+
The standby is only able to become a synchronous standby
1045+
once it has reached <literal>STREAMING</> state.
1046+
</para>
1047+
1048+
<para>
1049+
If primary restarts while commits are waiting for acknowledgement, those
1050+
waiting transactions will be marked fully committed once the primary
1051+
database recovers.
1052+
There is no way to be certain that all standbys have received all
1053+
outstanding WAL data at time of the crash of the primary. Some
1054+
transactions may not show as committed on the standby, even though
1055+
they show as committed on the primary. The guarantee we offer is that
1056+
the application will not receive explicit acknowledgement of the
1057+
successful commit of a transaction until the WAL data is known to be
1058+
safely received by the standby.
1059+
</para>
1060+
1061+
<para>
1062+
If you really do lose your last standby server then you should disable
1063+
<varname>synchronous_standby_names</> and restart the primary server.
1064+
</para>
1065+
1066+
<para>
1067+
If the primary is isolated from remaining standby severs you should
1068+
failover to the best candidate of those other remaining standby servers.
1069+
</para>
1070+
1071+
<para>
1072+
If you need to re-create a standby server while transactions are
1073+
waiting, make sure that the commands to run pg_start_backup() and
1074+
pg_stop_backup() are run in a session with
1075+
synchronous_replication = off, otherwise those requests will wait
1076+
forever for the standby to appear.
1077+
</para>
1078+
1079+
</sect3>
1080+
</sect2>
8781081
</sect1>
8791082

8801083
<sect1 id="warm-standby-failover">

‎doc/src/sgml/monitoring.sgml‎

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -306,8 +306,11 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
306306
location. In addition, the standby reports the last transaction log
307307
position it received and wrote, the last position it flushed to disk,
308308
and the last position it replayed, and this information is also
309-
displayed here. The columns detailing what exactly the connection is
310-
doing are only visible if the user examining the view is a superuser.
309+
displayed here. If the standby's application names matches one of the
310+
settings in <varname>synchronous_standby_names</> then the sync_priority
311+
is shown here also, that is the order in which standbys will become
312+
the synchronous standby. The columns detailing what exactly the connection
313+
is doing are only visible if the user examining the view is a superuser.
311314
The client's hostname will be available only if
312315
<xref linkend="guc-log-hostname"> is set or if the user's hostname
313316
needed to be looked up during <filename>pg_hba.conf</filename>

‎src/backend/access/transam/twophase.c‎

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -56,6 +56,7 @@
5656
#include"pg_trace.h"
5757
#include"pgstat.h"
5858
#include"replication/walsender.h"
59+
#include"replication/syncrep.h"
5960
#include"storage/fd.h"
6061
#include"storage/predicate.h"
6162
#include"storage/procarray.h"
@@ -1071,6 +1072,14 @@ EndPrepare(GlobalTransaction gxact)
10711072

10721073
END_CRIT_SECTION();
10731074

1075+
/*
1076+
* Wait for synchronous replication, if required.
1077+
*
1078+
* Note that at this stage we have marked the prepare, but still show as
1079+
* running in the procarray (twice!) and continue to hold locks.
1080+
*/
1081+
SyncRepWaitForLSN(gxact->prepare_lsn);
1082+
10741083
records.tail=records.head=NULL;
10751084
}
10761085

@@ -2030,6 +2039,14 @@ RecordTransactionCommitPrepared(TransactionId xid,
20302039
MyProc->inCommit= false;
20312040

20322041
END_CRIT_SECTION();
2042+
2043+
/*
2044+
* Wait for synchronous replication, if required.
2045+
*
2046+
* Note that at this stage we have marked clog, but still show as
2047+
* running in the procarray and continue to hold locks.
2048+
*/
2049+
SyncRepWaitForLSN(recptr);
20332050
}
20342051

20352052
/*
@@ -2109,4 +2126,12 @@ RecordTransactionAbortPrepared(TransactionId xid,
21092126
TransactionIdAbortTree(xid,nchildren,children);
21102127

21112128
END_CRIT_SECTION();
2129+
2130+
/*
2131+
* Wait for synchronous replication, if required.
2132+
*
2133+
* Note that at this stage we have marked clog, but still show as
2134+
* running in the procarray and continue to hold locks.
2135+
*/
2136+
SyncRepWaitForLSN(recptr);
21122137
}

‎src/backend/access/transam/xact.c‎

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,7 @@
3737
#include"miscadmin.h"
3838
#include"pgstat.h"
3939
#include"replication/walsender.h"
40+
#include"replication/syncrep.h"
4041
#include"storage/bufmgr.h"
4142
#include"storage/fd.h"
4243
#include"storage/lmgr.h"
@@ -1055,7 +1056,7 @@ RecordTransactionCommit(void)
10551056
* if all to-be-deleted tables are temporary though, since they are lost
10561057
* anyway if we crash.)
10571058
*/
1058-
if ((wrote_xlog&&XactSyncCommit)||forceSyncCommit||nrels>0)
1059+
if ((wrote_xlog&&XactSyncCommit)||forceSyncCommit||nrels>0||SyncRepRequested())
10591060
{
10601061
/*
10611062
* Synchronous commit case:
@@ -1125,6 +1126,14 @@ RecordTransactionCommit(void)
11251126
/* Compute latestXid while we have the child XIDs handy */
11261127
latestXid=TransactionIdLatest(xid,nchildren,children);
11271128

1129+
/*
1130+
* Wait for synchronous replication, if required.
1131+
*
1132+
* Note that at this stage we have marked clog, but still show as
1133+
* running in the procarray and continue to hold locks.
1134+
*/
1135+
SyncRepWaitForLSN(XactLastRecEnd);
1136+
11281137
/* Reset XactLastRecEnd until the next transaction writes something */
11291138
XactLastRecEnd.xrecoff=0;
11301139

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp