You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Alexander Shraer (JIRA)" <ji...@apache.org> on 2013/07/13 21:37:49 UTC

[jira] [Commented] (ZOOKEEPER-1727) Doc request: The right way to expand a cluster

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707821#comment-13707821 ] 

Alexander Shraer commented on ZOOKEEPER-1727:
---------------------------------------------

Hi Justin,

Thanks for all the comments!

I've written a user guide draft, please let me know if something doesn't work as described, missing, etc:
https://issues.apache.org/jira/browse/ZOOKEEPER-1660

To your question - for a reconfiguration to work we need a quorum (majority) of the old and the new config. 
This way we can ensure that the state is always stored on a majority of the servers.  In your case we need 2 out of 2 old servers and 2 out of 3 new servers. This is why reconfiguration goes through even if server 3 is not up yet. 

I'm not sure why you get a connection loss error. If this is happening even when you're following the document linked above, please describe the steps to reproduce including the config files, and to which server the disconnecting client is connected.

Thanks,
Alex


                
> Doc request: The right way to expand a cluster
> ----------------------------------------------
>
>                 Key: ZOOKEEPER-1727
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1727
>             Project: ZooKeeper
>          Issue Type: Wish
>    Affects Versions: 3.5.0
>            Reporter: Justin SB
>            Priority: Minor
>
> When expanding a cluster from 2->3, if ZK server #3 isn't up yet, then it seems that the reconfig request times out with a connection-loss error.  The configuration is updated though.  So we could wait, reconnect, and then refetch the config to make sure we did join the quorum, though that seems a little bit hacky!
> What is correct way to do this (and cluster growth in general)?  Should we bring up new ZK servers before issuing the reconfig command?  What is the right way to bring up new ZK servers (connect as a client, request the config, save the config to the zk.conf.dynamic file, add our new server line to the new zk.conf.dynamic file, start the new server, call reconfig as a client to the existing cluster)?
> Is this documented anywhere? (Just the steps to do it "the right way" would be great, no need for actual code) :-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira