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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers