[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706320#action_12706320
]
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
rollback.
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.
