zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: Dynamic reconfiguration
Date Sat, 28 Jul 2012 00:25:27 GMT
BTW, please don't hesitate to ask me if you have other questions or run
into any issues with ZK-107 patch.

On Fri, Jul 27, 2012 at 5:20 PM, Alexander Shraer <shralex@gmail.com> wrote:

> Hi Jared,
> Thanks for experimenting with this feature.
> The idea is that new servers join as "non voting followers". Which means
> that they act as normal followers but the leader ignores their votes since
> they are not part of the current configuration. The leader only counts
> their votes during the reconfiguration itself (to make sure a quorum of the
> new config is ready before the new config can be committed/activated).
> Defining them as observers is not a good idea, for example in your scenario
> if they were observers they wouldn't be able to participate in the
> reconfiguration protocol (which is similar to the protocol for committing
> any other operation in which observers don't participate) and since we
> don't have a quorum of followers in the new config that can ack,
> reconfiguration would throw an exception (of
> KeeperException.NEWCONFIGNOQUORUM type).
> Of course if you intend them to be observers in the new config you can
> define them as observers since their votes are not needed during reconfig
> anyway.
> You're right, the new servers must be able to connect to the old quorum.
> At minimum, their file should contain the current leader, but
> you can also copy the current configuration file to the new members if you
> wish.
> In addition, you should add a line for the member itself, so that server F
> appears in F's config file (Its not important that the other new servers
> appear in F's file, but it won't hurt either, so you can do a union of old
> and new if you wish). The constructor of QuorumPeer checks that the server
> itself is in the configuration its started with, otherwise its not going to
> run. This check has always been there, but I'm thinking of possibly
> changing it in the future.
> As soon as F connects to the leader, its config file will be overwritten
> with the current config file as part of the synchronization process.
> Alex
> On Fri, Jul 27, 2012 at 10:06 AM, Jared Cantwell <jared.cantwell@gmail.com
> > wrote:
>> Hi,
>> We are testing integration with 3.5.0 and dynamic membership and I have a
>> question.  If I have a current set of servers in my ensemble {A,B,C,D,E}
>> and I want to reconfigure the ensemble to {D,E,F,G,H}, how should the
>> dynamic config file on servers F,G,H be configured on startup?  Should
>> they
>> have the old ensemble, the new ensemble, or the union of both ensembles?
>>  It seems like these new servers need to  know about the old quorum, but
>> since they aren't part of it yet its not clear to me how they should be
>> configured.  Should there be an intermediate configuration with F,G, and H
>> as simply Observers?
>> I can't find much documentation on this so I want to make sure I
>> understand
>> things correctly.
>> Thanks!
>> ~Jared

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message