Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Ensure there is one master


Copy link to this message
-
Re: Ensure there is one master
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" <[EMAIL PROTECTED]> 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+[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB