[infinispan-dev] dealing with cluster partitions (design wiki) WAS ( design for cluster events (wiki page))

[Mircea Markus]

On Oct 30, 2013, at 7:28 PM, William Burns <mudokonman at gmail.com> 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.

agreed.

>  But the 3 nodes that are "writable" can't be
> accessed any longer and thus no writes can be performed on the
> cluster.  It seems we would still want to allow writes to provide as
> high of availability as possible.

we actually don't take the decision for the user but to plug in his own PartitionHandlingStrategy to make a wiser decision based on their network specifics.
The quorum approach written there is just a suggestion, I'll make that clearer.

> 
> Also if we did have read only, what criteria would cause those nodes
> to be writeable again?

Changing the availability status is possible through JMX, so either manual intervention or some MergeListeners that do that automatically.

>  There is no guarantee when the other nodes
> will ever come back up or if there will ever be additional ones
> anytime soon.
> 
> - Will
>> [1] https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions

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