Re: Issues with Quorum Commit

On Fri, Oct 8, 2010 at 5:16 PM, Markus Wanner <markus(at)bluegap(dot)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