[infinispan-dev] design for cluster events (wiki page)

[Mircea Markus]

On Oct 31, 2013, at 1:25 PM, Bela Ban <bban at redhat.com> wrote:

>>>> On 10/30/13 8:28 PM, William Burns wrote: Since it seems I can't
>>>> comment on the wiki itself, I am just replying here.
>>>> 
>>>> I wonder if the third option 'Primary partition' is desirable.
>>>> I think availability in some cases would be harmed more than we
>>>> would like.
>>>> 
>>>> Lets say you have a 5 node cluster where 3 of the nodes are
>>>> behind the same router and the remaining 2 are behind a different
>>>> one.  If the router crashes, power loss etc. for the 3 and are no
>>>> longer addressable you have your 2 partitions (possibly 1 or even
>>>> 4).  When this occurs the other 2 nodes would go into read only
>>>> mode since they lost the quorum check.
>>> 
>>> Yes, this is intended. Actually, the minority partition {D,E} might
>>> even become totally inaccessible, ie. rejecting *all* requests
>>> (also reads).
>>> 
>>> This is in line with the Primary Partition approach where a
>>> majority partition is allowed to make progress, and all minority
>>> partitions shut down. In terms of CAP, we're sacrificing
>>> availabilty here in favor of consistency.
>>> 
>>>> But the 3 nodes that are "writable" can't be accessed any longer
>>>> and thus no writes can be performed on the cluster.
>>> 
>>> You mean some clients cannot access {A,B,C} ? Sure, then so be it,
>>> but at least we don't have any inconsistent state. Again, PP is
>>> *one* tool we give to th user to handle partitions.
>>> 
>>>> It seems we would still want to allow writes to provide as high
>>>> of availability as possible.
>>> 
>>> PP is *not* about availability, it is about consistency.
>> 
>> I think it's about availability as well, as the primary partition is still available.
> 
> Note that with a Primary Partition approach, *no* partition might be the 
> primary partition and thus availablity would be impacted.

I was having in mind the strategy in which a partition is declared as primary and kept active if it has n/2+1 members. That doesn't guarantee consistency on the PP.


Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)