Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of shralex@gmail.com designates
 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANykdubj=bi1GHCBUV-xH5ucTg-EyQvqpjCagpFBjhmkLDdt+A@mail.gmail.com>
References: <1385456084052-7579367.post@n2.nabble.com>
 <CAKF1A=vwWH+4EiUZrHc9ZXbxMOkxe+DcYJRKw8+zOuvnL9bRdw@mail.gmail.com>
 <1385504882746-7579376.post@n2.nabble.com>
 <CANykdubj=bi1GHCBUV-xH5ucTg-EyQvqpjCagpFBjhmkLDdt+A@mail.gmail.com>
From: Alexander Shraer <shralex@gmail.com>
Date: Tue, 26 Nov 2013 14:58:31 -0800
Message-ID: 
 <CANcXBFMJQDtRU897J0y7U-4z=M=ow7kSeg_zgxj-qSG5gbvb7A@mail.gmail.com>
Subject: Re: Ensure there is one master
To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Cameron's solution basically relies on additional timing assumptions
as Maciej mentions in his question.

One more thing you could do is to implement increasing generation ids
for masters, and have clients in your system reject commands from a
master if they already know that a master with a higher generation id
was elected (either because they saw a command from the new master or
because they got a notification from ZK). This way each client can
only have a single master and goes forward in time.

Alex

On Tue, Nov 26, 2013 at 2:34 PM, Cameron McKenzie
<mckenzie.cam@gmail.com> wrote:
> If I'm understanding your question correctly, you're worried that when the
> current 'master' loses its connection to ZooKeeper, a new 'master' will be
> elected and you will have 2 'master' nodes at the same time. As soon as you
> lose a connection to ZooKeeper there are no guarantees about any of the
> state that you're determining from it. When you lose the ZooKeeper
> connection, your 'master' must assume that it is no longer a 'master' node
> until it reconnects to ZooKeeper, at which point it will be able to work
> out what's going on.
>
> If you look at Apache Curator, its implementation of the Leader latch
> recipe handles this loss of connection and reestablishment.
>
> cheers
> Cam
>
>
> On Wed, Nov 27, 2013 at 9:28 AM, ms209495 <jezdnia@gmail.com> wrote:
>
>> Thanks for the reply. I want to clarify one thing.
>> I think about a System of 20 nodes, that uses ZooKeeper of 3 nodes.
>> I think about master election among these 20 nodes, that do not run
>> consensus, but they use zookeeper service for master election.
>> I used 'leader' term for a leeder in Zookeeper (among 3 nodes), and
>> 'master'
>> term for master in the System (20 nodes).
>> Solution is described here:
>> http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection (I
>> would name it 'master' election, not 'leader' election), but I doubt if it
>> works reliable without additional timing assumptions as I described in my
>> previous post.
>> Please consider my previous post in the context of the System that uses
>> Zookeeper (not ZooKeeper itself).
>>
>>
>>
>> --
>> View this message in context:
>> http://zookeeper-user.578899.n2.nabble.com/Ensure-there-is-one-master-tp7579367p7579376.html
>> Sent from the zookeeper-user mailing list archive at Nabble.com.
>>