Thank you all for your answers. It clarifies a lot of my confusion about the
service guarantees of ZK. I am still struggling with one failure case (I am
not trying to be the pain in the neck. But I need to have a full
understanding of what ZK can offer before I make a decision on whether to
used it in my cluster.)
Assume the following topology:
Leader ==== ZK cluster
\\ //
\\ //
\\ //
Slave(s)
If I am asymmetric network failure such that the connection between Leader
and Slave(s) are broken while all other connections are still alive, would
my system hang after some point? Because no new leader election will be
initiated by slaves and the leader can't get the work to slave(s).
Thanks,
Lei
On 4/30/10 1:54 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
> If one of your user clients can no longer reach one member of the ZK
> cluster, then it will try to reach another. If it succeeds, then it will
> continue without any problems as long as the ZK cluster itself is OK.
>
> This applies for all the ZK recipes. You will have to be a little bit
> careful to handle connection loss, but that should get easier soon (and
> isn't all that difficult anyway).
>
> On Fri, Apr 30, 2010 at 1:26 PM, Lei Gao <l...@linkedin.com> wrote:
>
>> I am not talking about the leader election within zookeeper cluster. I
>> guess
>> I didn't make the discussion context clear. In my case, I run a cluster
>> that
>> uses zookeeper for doing the leader election. Yes, nodes in my cluster are
>> the clients of zookeeper. Those nodes depend on zookeeper to elect a new
>> leader and figure out what the current leader is. So if the zookeeper
>> (think
>> of it as a stand-alone entity) becomes unavailabe in the way I've described
>> earlier, how can I handle such situation so my cluster can still function
>> while a majority of nodes still connect to each other (but not to the
>> zookeeper)?
>>
