Re: Issues with Quorum Commit
От | Markus Wanner |
---|---|
Тема | Re: Issues with Quorum Commit |
Дата | |
Msg-id | 4CAED348.2020304@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Issues with Quorum Commit (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Issues with Quorum Commit
|
Список | pgsql-hackers |
On 10/08/2010 05:41 AM, Fujii Masao wrote: > But, even with quorum commit, if you choose wait-forever option, > failover would decrease availability. Right after the failover, > no standby has connected to new master, so if quorum >= 1, all > the transactions must wait for a while. That's a point, yes. But again, this is just write-availability, you can happily read from all active standbies. And connection time is certainly negligible compared to any kind of timeout (which certainly needs to be way bigger than a couple of network round-trips). > Basically we need to take a base backup from new master to start > the standbys and make them connect to new master. This might take > a long time. Since transaction commits cannot advance for that time, > availability would goes down. Just don't increase your quorum_commit to unreasonable values which your hardware cannot possible satisfy. It doesn't make sense to set a quorum_commit of 1 or even bigger, if you don't already have a standby attached. Start with 0 (i.e. replication off), then add standbies, then increase quorum_commit to your new requirements. > Or you think that wait-forever option is applied only when the > standby goes down? That wouldn't work in case of a full-cluster crash, where the wait-forever option is required again. Otherwise you risk a split-brain situation. Regards Markus Wanner
В списке pgsql-hackers по дате отправления: