[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619106#action_12619106
]
Hiram Chirino commented on ZOOKEEPER-107:
-----------------------------------------
I personally think that this needs to stay decoupled so that group membership
can be controlled via different implementations. In other words, I think that
the QuorumPeer should not have to have any constructor args for it to know it's
peers. It should persistently store/remember what the list of peers are part
of the group since it last started.
Not sure if it makes sense to keep that list in the ZK db or not.
When a node that is not part of a cluster first starts up, it needs to know if
it's starting a new cluster or if it is joining an existing cluster.
Therefore, I think the QuorumPeer class needs methods like the following:
{code}
/**
* Contacts a ZK server in the cluster, adds this peer to the cluster and gets
a listing of the rest of the peers in
* the cluster.
*
* Optional: is slaveOnly is true, then this peer should never be elected
master.
*
* Throws an error if this peer is already part of a cluster.
*/
void joinCluster( URI server, bool slaveOnly )
/**
* Starts this peer as the first node in the cluster and makes him the master.
*
* Throws an error if this peer is already part of a cluster.
*/
void createCluster()
/**
* Removes this peer from the peer list maintained by the cluster.
*
* Throws an error if this peer is not part of a cluster.
*/
void leaveCluster()
/**
* Gets a list of peers in the cluser.
*
* @return null if not part of a cluster yet.
*/
List<URI> getClusterPeers()
{code}
If methods like the above are available, then an administrator can dynamically
manage adding/removing nodes on an existing ZooKeeper cluster. or some
automated agent could do it. Note that the peer list needs to get replicated
to all cluster members and persisted to avoid split brain issues on peer
restart. Operations like joinCluster(), leaveCluster(), getClusterPeers()
would block until a master is elected in the cluster.
Please note the 'nice to have feature' where you have the ability to designate
some peers as NOT being eligible to become a master. This would allow you to
support using heterogeneous peers, and enforce only allowing the higher end
machines to become the masters.
> 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.
