You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Maciej Smoleński <je...@gmail.com> on 2013/11/26 15:34:40 UTC
Ensuring there is at most one master
Hi,
ZooKeeper is an excellent system. The problem with ensuring only one
master among clients bothers me.
Lets have a look at the situation when network partition happen: there
is part A (majority), and part B (minority).
Lets assume that before network partition happened the master was
connected to part B.
After the network partition, part A will elect new ZooKeeper leader,
and there will be new master elected among clients connected to part
A.
At this time there are two masters - old in part B, and new in part A.
The only solution I can think about to this problem, is to ensure that
the new master is inactive for some time - to ensure that the old
master in this time will detect that it is not connected to ZooKeeper
quorum, and will deactivate itself as a master.
This solution assumes that timers on these machines work correctly.
Is it possible to ensure only one master using ZooKeeper without
timing assumptions ?
Thanks,
Maciej
Re: Ensuring there is at most one master
Posted by Maciej Smoleński <je...@gmail.com>.
This problem is discussed here:
http://zookeeper-user.578899.n2.nabble.com/Ensure-there-is-one-master-td7579367.html#a7579390.
Maciej
On 12/2/13, Neha Narkhede <ne...@gmail.com> wrote:
>>> At this time there are two masters - old in part B, and new in part A.
>
> After the network partition, there shouldn't be a leader in part B since it
> is a minority and will not be able to form a quorum.
>
> Thanks,
> Neha
>
>
> On Tue, Nov 26, 2013 at 6:34 AM, Maciej Smoleński <je...@gmail.com>
> wrote:
>
>> Hi,
>>
>> ZooKeeper is an excellent system. The problem with ensuring only one
>> master among clients bothers me.
>>
>> Lets have a look at the situation when network partition happen: there
>> is part A (majority), and part B (minority).
>> Lets assume that before network partition happened the master was
>> connected to part B.
>> After the network partition, part A will elect new ZooKeeper leader,
>> and there will be new master elected among clients connected to part
>> A.
>> At this time there are two masters - old in part B, and new in part A.
>> The only solution I can think about to this problem, is to ensure that
>> the new master is inactive for some time - to ensure that the old
>> master in this time will detect that it is not connected to ZooKeeper
>> quorum, and will deactivate itself as a master.
>> This solution assumes that timers on these machines work correctly.
>> Is it possible to ensure only one master using ZooKeeper without
>> timing assumptions ?
>>
>> Thanks,
>> Maciej
>>
>
Re: Ensuring there is at most one master
Posted by Neha Narkhede <ne...@gmail.com>.
>> At this time there are two masters - old in part B, and new in part A.
After the network partition, there shouldn't be a leader in part B since it
is a minority and will not be able to form a quorum.
Thanks,
Neha
On Tue, Nov 26, 2013 at 6:34 AM, Maciej Smoleński <je...@gmail.com> wrote:
> Hi,
>
> ZooKeeper is an excellent system. The problem with ensuring only one
> master among clients bothers me.
>
> Lets have a look at the situation when network partition happen: there
> is part A (majority), and part B (minority).
> Lets assume that before network partition happened the master was
> connected to part B.
> After the network partition, part A will elect new ZooKeeper leader,
> and there will be new master elected among clients connected to part
> A.
> At this time there are two masters - old in part B, and new in part A.
> The only solution I can think about to this problem, is to ensure that
> the new master is inactive for some time - to ensure that the old
> master in this time will detect that it is not connected to ZooKeeper
> quorum, and will deactivate itself as a master.
> This solution assumes that timers on these machines work correctly.
> Is it possible to ensure only one master using ZooKeeper without
> timing assumptions ?
>
> Thanks,
> Maciej
>