On 05/13/2014 12:08 AM, Borodin Vladimir wrote:
12 мая 2014 г., в 22:26, Adrian Klaver <adrian.klaver@xxxxxxxxxxx
<mailto:adrian.klaver@xxxxxxxxxxx>> написал(а):
On 05/12/2014 09:42 AM, Borodin Vladimir wrote:
Hi all.
Right now synchronous replication in postgresql chooses one replica as
synchronous and waits for replies from it (with synchronous_commit = on
| remote_write) until this replica host does not disconnect from master.
Are there any plans to implement something like semi synchronous
replication in MySQL 5.6 or replication with write_concern=2 in MongoDB
when the master waits for a reply from any of the replica hosts?
This does not work for what you want?:
http://www.postgresql.org/docs/9.3/interactive/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES
Actually no. I have such settings:
wal_sender_timeout = 3s
wal_receiver_status_interval = 1s
synchronous_standby_names = ‘*’
When the sync replica dies or the network between master and sync
replica flaps, 3 seconds must pass before the potential replica becomes
sync and transaction commits continue. Instead postgresql could wait for
confirm from first or second replica hosts (doesn’t matter which of them
answers first), couldn’t it? In this case transaction commits will not
stuck for wal_sender_timeout.
Postgres is doing what you tell it. You have said you are willing to
waits 3 secs for any inactivity between the master and the standby to
resolve itself before declaring that particular connection dead. Once
that happens then Postgres starts working through the list of names. The
wal_sender_timeout value by default is in milliseconds so you can make
that value very small. It would seem prudent to have some value there in
order to deal with temporary network hiccups.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
