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