On Fri, Oct 8, 2010 at 5:16 PM, Markus Wanner <mar...@bluegap.ch> wrote: > 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.
I believe many systems require write-availability. >> 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. No. This only makes the procedure of failover more complex. >> 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. What is a full-cluster crash? Why does it cause a split-brain? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
