Well there are real limits about what knowledge you can have in a split brain and how much coordination there can be.
Having exactly one master in such situation is impossible. You get to pick your error scenario, however. One option is to have one master almost all the time with a failure mode of having zero acting masters a bit of the time. The other option is to have one master almost all the time with a failure mode that has two masters a bit of the time. You get to pick which one. As Ben stated, the philosophy of ZK is to report facts that can be demonstrated. Your application will work pretty well with a timer even though that could result in momentary double master situations. Of course, it can also result in periods of zero master as well since a master cut off from ZK may well be cut off from the clients who want to be served. So the API isn't making a promise it can't keep. It is promising to report to you as soon as it is certain of things. And it does. On Fri, Apr 22, 2011 at 6:51 AM, Scott Fines <[email protected]> wrote: > I guess my objection would be that the API is making a promise that it can > only deliver part of the time. If the client can't reconnect to ZooKeeper, > then the client hasn't expired, which is an unusual state to find oneself > in, and in leader-election systems like mine could result in having two > practical leaders, while ZooKeeper is insisting that there is only one. > This > kind of split-brain scenario seems unavoidable in the absence of > probabilistic failure checking (like timeouts). > > The FAQ, I've noticed, does make mention of this phenomenon. Perhaps > something should be indicated there regarding the why and not just the > mechanics. Otherwise, developers such as myself might find themselves > unduly > confused by it :) > > Thanks for all your help, >
