Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Dynamic reconfiguration


Copy link to this message
-
Re: Dynamic reconfiguration
Yes, this entry will be deleted. I don't like this either - if a new
follower reboots before added to the config it will not be able to boot up
without manual help from an admin. That's why I'm considering maybe to
remove the check that a participant must always initially be in its own
config, but for now its there.

Alex

On Fri, Jul 27, 2012 at 6:34 PM, Jared Cantwell <[EMAIL PROTECTED]>wrote:

> Sorry for the confusion in terminology, I was unfamiliar with the exact
> leader/follower semantics previously.
>
> So if all connected servers update their config file, does that mean that
> non-voting followers who aren't part of the new ensemble will lose the
> entry specific to them in their config file?  I can test this myself, but
> getting an inside perspective is very helpful.
>
> Thanks again for the help!
> Jared
>
>
> On Jul 27, 2012, at 6:55 PM, Alexander Shraer <[EMAIL PROTECTED]> wrote:
>
> Yes, any number of followers which are not in the configuration can just
> connect and listen in. This has always been the case, also in 3.4, I just
> made use of this for the purpose of adding members during reconfiguration.
> Moreover, in 3.4 there this bug ZOOKEEPER-1113<https://issues.apache.org/jira/browse/ZOOKEEPER-1113>
> where the leader actually counts the votes of anyone connected, regardless
> of config membership :) This is fixed in ZK-107, so they are really
> non-voting followers.
>
> >   I am assuming that's the case, and that it is a follower (and not
> > participant) by virtue of not being in the official configuration stored
> in
> > zookeeper itself.
>
> Follower and participant types of servers is not something that was
> defined in ZK-107. In ZooKeeper every follower/leader is a "participant".
> Its just that the votes of participants that are not in the configuration
> are not counted that's why we call them non-voting followers. BTW,
> obviously a non-voting follower can not become leader (like ZK-1113 this
> was also not enforced before ZK-107).
>
> > And a followup... does zookeeper only overwrite the dynamic
> > configuration file for nodes that are voting participants?  Such that if
> I
> > started a follower and then left it running through some
> > reconfigurations, its file would not get updated if it was never added
> as
> > part of those reconfigurations?
>
> No, as soon as it connects to the current leader, its dynamic config file
> is overwritten with the current configuration as part of the
> synchronization with the leader. Every time a new configuration is
> committed, all connected servers (voting, non-voting, observers) will
> update their dynamic config file, doesn't matter if they're in the config.
>
> Alex
>
> On Fri, Jul 27, 2012 at 5:35 PM, Jared Cantwell <[EMAIL PROTECTED]>wrote:
>
>> So does just having the server started and pointing to the existing
>> ensemble automatically make it a "non participating follower"?  In other
>> words, there is no need to inform the existing nodes that this new node is
>> joining as a follower?  And to extend that, there could be any number of
>> followers that are simply listening in on the event stream?  I am assuming
>> that's the case, and that it is a follower (and not participant) by virtue
>> of not being in the official configuration stored in zookeeper itself.
>>
>> On Fri, Jul 27, 2012 at 6:29 PM, Alexander Shraer <[EMAIL PROTECTED]>wrote:
>>
>>> there are just two supported types - participant and observer.
>>> (participant can act as either follower or leader).
>>>
>>> So you can either write participant or leave it unspecified (which means
>>> participant by default). Also, since the ip is the same for all your ports
>>> you don't have to write it twice.  All of these should work in the same way:
>>>
>>> server.5=10.10.5.17:2182:2183:participant;10.10.5.17:2181
>>> server.5=10.10.5.17:2182:2183:participant;2181 <http://10.10.5.17:2181/>
>>> server.5=10.10.5.17:2182:2183;10.10.5.17:2181
>>> server.5=10.10.5.17:2182:2183;2181 <http://10.10.5.17:2181/>