Hi Lei -
The 'user cluster' (by which I think you mean the set of clients of
ZooKeeper?) plays no part in leader election. If a majority of ZooKeeper
server nodes can talk to each other, a new leader can be elected. Clients of
the minority server partition will be disconnected - if they too cannot
reach the majority partition then they will not be able to reconnect.
Hope this helps,
On 30 April 2010 12:45, Lei Gao <l...@linkedin.com> wrote:
> Hi Ted,
> I 100% agree with what you said. But my question is more about what if my
> zookeeper service cluster is partitioned from a majority of nodes in my USER
> CLUSTER. In this case, the majority nodes in one network partition can’t
> select a new leader because zookeeper is out of reach.
> Another example will be that if there is an asymmetric network failure
> where a majority of nodes from the USER CLUSTER can’t reach the leader while
> the zookeeper still can. How does zookeeper handle such situation?
> On 4/30/10 12:24 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
> There are a variety of situations that can trigger a new leader election
> and a few that can cause the cluster to be unable to elect a new leader.
> Isolation of just the leader is one of the situations that will cause a new
> leader election. Isolation of nodes into groups smaller than the quorum
> will result in the cluster freezing.
> On Fri, Apr 30, 2010 at 11:56 AM, Lei Gao <l...@linkedin.com> wrote:
> I have a general question on how zookeeper can maintain its view of the
> user cluster (that zookeeper manages) that is consistent with the nodes in
> the user cluster. In other words, when zookeeper considers the current
> leader is unavailable, does it really guarantee that a majority of nodes in
> the user cluster can’t reach the current leader? The same question applies
> to the membership service as well. Because the zookeeper can be partitioned
> from a majority of the nodes in the user cluster. How does the zookeeper
> handle situations like this?