On Oct 31, 2013, at 1:25 PM, Bela Ban <[email protected]> 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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
