Question about synchronous replication
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?
In this case network flaps between master and any one replica will not affect writing load and in case of master fail it would be necessary to find the most recent replica and promote it. Or there are pitfalls that I do not see?
--
Vladimir
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?:
In this case network flaps between master and any one replica will not
affect writing load and in case of master fail it would be necessary to
find the most recent replica and promote it. Or there are pitfalls that
I do not see?--
Vladimir
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
12 мая 2014 г., в 22:26, Adrian Klaver <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?:
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.
In this case network flaps between master and any one replica will not
affect writing load and in case of master fail it would be necessary to
find the most recent replica and promote it. Or there are pitfalls that
I do not see?--
Vladimir--
Adrian Klaver
adrian.klaver@aklaver.com
--
Да пребудет с вами сила...
http://simply.name
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?:
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general