On 05/13/2014 12:08 AM, Borodin Vladimir wrote:
>
> 12 мая 2014 г., в 22:26, Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> написал(а):
>
>> 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@aklaver.com