Re: Question about synchronous replication
| От | Borodin Vladimir |
|---|---|
| Тема | Re: Question about synchronous replication |
| Дата | |
| Msg-id | A128A363-AC21-4FD1-A579-0DD9F57C89AF@simply.name обсуждение исходный текст |
| Ответ на | Re: Question about synchronous replication (Adrian Klaver <adrian.klaver@aklaver.com>) |
| Ответы |
Re: Question about synchronous replication
|
| Список | 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?:
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.
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
В списке pgsql-general по дате отправления: