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, 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/>
>>
>>
>>
>> On Fri, Jul 27, 2012 at 5:25 PM, Jared Cantwell <[EMAIL PROTECTED]
>> > wrote:
>>
>>> Thanks Alex for the response.  Our current lines in the configuration
>>> look like this:
>>>
>>> server.5=10.10.5.17:2182:2183:participant;10.10.5.17:2181
>>>
>>> For the new servers is it ok for their entry to have "participant"?  Or
>>> should that be something different (e.g. "follower")?
>>>
>>> ~Jared
>>>
>>> On Fri, Jul 27, 2012 at 6:20 PM, Alexander Shraer <[EMAIL PROTECTED]>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