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

Switch to Plain View
Zookeeper, mail # user - Dynamic reconfiguration


+
Jared Cantwell 2012-07-27, 17:06
+
Alexander Shraer 2012-07-28, 00:20
+
Alexander Shraer 2012-07-28, 00:25
+
Jared Cantwell 2012-07-28, 00:25
+
Alexander Shraer 2012-07-28, 00:29
+
Jared Cantwell 2012-07-28, 00:35
+
Alexander Shraer 2012-07-28, 00:55
+
Jared Cantwell 2012-07-28, 01:34
+
Alexander Shraer 2012-07-28, 01:42
+
Jared Cantwell 2012-07-28, 02:57
+
Jared Cantwell 2012-07-28, 15:43
+
Alexander Shraer 2012-07-28, 17:02
+
Jared Cantwell 2012-07-28, 17:17
+
Alexander Shraer 2012-07-28, 17:33
+
Jared Cantwell 2012-07-28, 17:57
+
Alexander Shraer 2012-07-28, 18:15
+
Jared Cantwell 2012-07-28, 22:26
+
Alexander Shraer 2012-07-28, 23:36
+
Jared Cantwell 2012-07-28, 23:52
+
Alexander Shraer 2012-07-29, 01:00
+
Alexander Shraer 2012-07-28, 23:01
Copy link to this message
-
Re: Dynamic reconfiguration
Jared Cantwell 2012-07-28, 00:41
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?

~Jared

On Fri, Jul 27, 2012 at 6: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
>>>> 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