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

>>> 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.