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] <[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.
