Re: [infinispan-dev] dealing with cluster partitions (design wiki) WAS ( design for cluster events (wiki page))
On Oct 30, 2013, at 7:28 PM, William Burns <mudokonman(a)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)