zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: Ensure there is one master
Date Tue, 26 Nov 2013 23:27:24 GMT
Only read on exc if you are the leader. This is a low throughput solution since your access
to that region is globally single threaded. Suggest that you stage updates from exc to a region
that is highly available for readers. Of course, staging must be atomic, bryan

> On Nov 26, 2013, at 6:18 PM, "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.

View raw message