I think you might be confusing Leader Election within ZooKeeper itself with
electing a leader for your application? Is that so?
Leader Election within ZooKeeper is totally internal to zookeeper service
and is not visible to applications.
I am little confused, what your problem statement is? Can you please explain
it from the view point of your application?
On 4/30/10 12:45 PM, "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?