[rabbitmq-discuss] How robust is clustering, and under what conditions?

[Eugene Kirpichov]

Hi Matthias,


On Thu, Nov 15, 2012 at 5:51 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> Eugene,
>
>
> On 15/11/12 13:42, Eugene Kirpichov wrote:
>
>> Actually, why couldn't RabbitMQ use a majority quorum for determining
>> who's the most up-to-date guy?
>>
>> Assume 3 nodes: A, B, C. Assume that A is the leader.
>>
>> Stop A: now B and C elect a leader and, say, they elect B.
>> Stop B: now C knows it's no longer part of a quorum and it just sits
>> there unresponsive. B doesn't behave like a leader either (if it was
>> just partitioned and not killed). Ok.
>> Start A: A and C now form a quorum with C as the most up-to-date member;
>> they elect C as the leader and A synchronizes from C.
>> Start B: B synchronizes from C too.
>>
>
> The above stop/start sequence works perfectly fine in rabbit. The key is
> that C was running all the time.
>
> If, otoh, C had been stopped too then neither A and B would start until C
> comes up. I can't see how anything else would be possible w/o throwing away
> data since C is the *only* node containing the most recent version of the
> data.


Ok, suppose we stop A, then B [after which C becomes unresponsive], then C.
Now A starts up but is unresponsive because there's no quorum.
Now B starts up; and A,B form a quorum. B is the most up to date, and it
also has everything (or most of) what C had, because they formed a quorum a
while ago, so A synchronizes from B.

So - yeah, you're right, this would work with synchronous replication, but
not quite so with asynchronous.


>
>
> Matthias.
>



-- 
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
We're hiring! http://tinyurl.com/mirantis-openstack-engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121115/28807856/attachment.htm>