hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
Date Fri, 01 Aug 2008 19:42:31 GMT

    [ 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:

 * 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()

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.

View raw message