Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=received:user-agent:date:subject:from:to:message-id:
	thread-topic:thread-index:in-reply-to:mime-version:content-type:
	content-transfer-encoding:return-path:x-originalarrivaltime;
	b=k4E7402W07WnVmppKU0R5et4pnaisHLET67trxW635ABxTjZMOXt9GOySsWrx8mn
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Fri, 30 Apr 2010 13:33:54 -0700
Subject: Re: Question on maintaining leader/membership status in zookeeper
From: Mahadev Konar <mahadev@yahoo-inc.com>
To: <zookeeper-user@hadoop.apache.org>, Henry Robinson <henry@cloudera.com>
Message-ID: <C8008CC2.34E7E%mahadev@yahoo-inc.com>
Thread-Topic: Question on maintaining leader/membership status in zookeeper
Thread-Index: AcrolsyrVHaljpCxZU+a1Yj/KCnSLwAPrJWA//+QRICAAHxxAP//jxmA///95bw=
In-Reply-To: <C8008AFF.AE2%lgao@linkedin.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Hi Lei,
 In this case, its up to application to decide what to do when this happens=
.
The application will be notified that its disconnected from the ZooKeeper
cluster. In such a case some of the applications might decide to not procee=
d
at all, (since it might lead to some state corruption) and some others migh=
t
decide on using cached values, wherein stale values are fine for correctnes=
s
of the system. Its up to you to decide what you would want to do in such a
situation.


Also, usually you would want to set up ZooKeeper clusters in such a way tha=
t
this should not be possible... Like across switches....

In this case, the application will be able to access one of the zookeeper
servers on the zookeeper cluster and it will be highly unlikely that they
arent able to reach any one of those.

Hope this helps.

Thanks
mahadev


On 4/30/10 1:26 PM, "Lei Gao" <lgao@linkedin.com> wrote:

> Hi Henry,
>=20
> I am not talking about the leader election within zookeeper cluster. I gu=
ess
> I didn't make the discussion context clear. In my case, I run a cluster t=
hat
> uses zookeeper for doing the leader election. Yes, nodes in my cluster ar=
e
> 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 (th=
ink
> of it as a stand-alone entity) becomes unavailabe in the way I've describ=
ed
> 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)?
>=20
> Thanks,
>=20
> Lei
>=20
>=20
> On 4/30/10 1:10 PM, "Henry Robinson" <henry@cloudera.com> wrote:
>=20
>> Hi Lei -
>>=20
>> 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. Client=
s of
>> the minority server partition will be disconnected - if they too cannot
>> reach the majority partition then they will not be able to reconnect.
>>=20
>> Hope this helps,
>> Henry
>>=20
>> On 30 April 2010 12:45, Lei Gao <lgao@linkedin.com> wrote:
>>=20
>>> Hi Ted,
>>>=20
>>> 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=
=B9t
>>> select a new leader because zookeeper is out of reach.
>>>=20
>>> Another example will be that if there is an asymmetric network failure
>>> where a majority of nodes from the USER CLUSTER can=B9t reach the leader =
while
>>> the zookeeper still can. How does zookeeper handle such situation?
>>>=20
>>> Thanks,
>>>=20
>>> Lei
>>>=20
>>> On 4/30/10 12:24 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>>>=20
>>> There are a variety of situations that can trigger a new leader electio=
n
>>> 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 quoru=
m
>>> will result in the cluster freezing.
>>>=20
>>> On Fri, Apr 30, 2010 at 11:56 AM, Lei Gao <lgao@linkedin.com> wrote:
>>> Hi,
>>>=20
>>> 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 node=
s in
>>> the user cluster can=B9t reach the current leader? The same question appl=
ies
>>> to the membership service as well. Because the zookeeper can be partiti=
oned
>>> from a majority of the nodes in the user cluster. How does the zookeepe=
r
>>> handle situations like this?
>>>=20
>>> Thanks,
>>>=20
>>> Lei
>>>=20
>>>=20
>>>=20
>>=20
>=20