Benjamin Reed commented on ZOOKEEPER-107:

the information needed for bootstrapping is the same as the information needed 
for a normal zookeeper client, so it could either use the standard string that 
is a list of host:port pairs, or it could use the scheme proposed in 
ZOOKEEPER-390. with that URL it could fetch /.zookeeper/ensemble and grab the 
configuration information that it needs. conf/zoo.cfg isn't really a good URI 
for this purpose since is doesn't really have the needed client ports. plus 
there is information in zoo.cfg that is particular to a given server. for 
example, the data and log directories may be different on all the machines. the 
client port should also probably stay in the zoo.cfg. the server lists and 
probably the timing variables should probably be stored in a znode and 
maintained with the atomic broadcast.

recovery is a bit more than you mention, but at the same time simpler. first 
off, to change quorum configuration you must commit the change in both the old 
quorum configuration and in the new quorum configuration. for example, if you 
have the configuration A, B, C and you are changing to A, B, C, D, E you must 
be able to get quorum in both the old and new configuration for the change to 
work. if only A and B are up or A, D, and E are up you cannot commit the 
change. this means that the leader should check the new configuration carefully 
before proposing it, because we always roll the proposals forward, we never 

so really a zookeeper server doesn't know whether he is able to participate or 
not, the election will sort it out. a simple example is an ensemble A, B, C, D, 
E. E goes down. the last zxid it saw was <57,3>. while it is down the quorum 
configuration gets changed to A, B, C by <57,52>. lets say there is a 
leadership change and at <58,6> the power goes out and comes back on. E now 
tries to vote (it thinks it is permitted to participate), but it won't win any 
election since its zxid is too low. A, B, and C will ignore E's votes anyway 
because they know that E has been removed from the ensemble.

> Allow dynamic changes to server cluster membership
> --------------------------------------------------
>                 Key: ZOOKEEPER-107
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: server
>            Reporter: Patrick Hunt
> Currently cluster membership is statically defined, adding/removing hosts 
> to/from the server cluster dynamically needs to be supported.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to