zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Ensure there is one master
Date Tue, 26 Nov 2013 23:41:56 GMT
I'm not sure on the exact details of how the connection loss is detected,
but in my experience, it is detected very quickly. Regardless, there will
still be an ephemeral node indicating that the old 'master' that is
connected to part B that will hang around until the old 'master's ZooKeeper
session times out. No new leader will be elected until this ephemeral node
has disappeared, and the old 'master' will definitely know that its
connection is gone by this point.


On Wed, Nov 27, 2013 at 10:17 AM, Maciej <jezdnia@gmail.com> wrote:

> Old master in part B will notice that the connection is broken after some
> time.
> New master can be elected in part A earlier.
>
> Let.s say that the system uses a shared disk (SAN).
> There is some area on the disk that must be used exclusively (let's
> name it EXC).
>
> During this short period of time:
>
> new master will receive a user request, will modify EXC area, and reply to
> user
> old master will also receive another user request, will read EXC data
> (during modification by new master) - reading inconsistent data, and
> will reply to user - with inconsistent data
>
> I wonder how to avoid such inconsistency.
>
>
> On 11/26/13, Cameron McKenzie [via zookeeper-user]
> <ml-node+s578899n7579377h23@n2.nabble.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.
> >>
> >
> >
> >
> >
> > _______________________________________________
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> http://zookeeper-user.578899.n2.nabble.com/Ensure-there-is-one-master-tp7579367p7579377.html
> >
> > To unsubscribe from Ensure there is one master, visit
> >
> http://zookeeper-user.578899.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7579367&code=amV6ZG5pYUBnbWFpbC5jb218NzU3OTM2N3wtNjE5OTg1Mjcw
>
>
>
>
> --
> View this message in context:
> http://zookeeper-user.578899.n2.nabble.com/Ensure-there-is-one-master-tp7579367p7579379.html
> Sent from the zookeeper-user mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message