To be explicit on a (probably) obvious point, you will have a few tens of seconds of downtime during the restart of server 1 until the second server comes on-line and participates in the election.
It there is a difference between 10 seconds of downtime and 2 minutes of downtime in your application, I recommend going from 1 to 3 nodes first then to 3+. It is easier to have a very short downtime when only a single additional node needs to come up. You might also be able to start server 2 before you bounce server 1, but you have to be very careful not to start enough machines to have a quorum before server 1 joins in. 2011/5/5 Patrick Hunt <[email protected]> > Hi Jared, you can go from 1 to 2+ nodes just fine: > > 1) change the configuration of server 1 from standalone to quorum > based (be sure to list the new members of the ensemble) > 2) add a myid file for server 1 > 3) setup new servers 2+ > 4) restart server 1 > 5) start servers 2+ > > At this point the quorum should just come up. I just tried this > example and it worked fine for me going from 1 to 3 (the data I > created in standalone was available once I started the ensemble). > > Regards, > > Patrick > > 2011/5/5 Jared Cantwell <[email protected]>: > > Great information guys-- this helps me understand what needs done when > > expanding from 2 nodes to X nodes. > > > > Does anyone have insight on going from 1 node to 3 nodes? > > > > ~Jared > > > > 2011/5/5 Chang Song <[email protected]> > > > >> > >> We are in a bit similar situation. > >> > >> 3 node -> 5 node ensemble. > >> > >> The only way to do this is the following. > >> > >> Assumption is that we have one DNS hostname for three zookeeper ensemble > >> IP. > >> Since five node ensemble allows 2 node failure for quorum, we can do > >> > >> > >> 0. First all two new ensemble IPs > >> > >> 1. change all three existing node config (zoo.cfg) and add two new node > >> information > >> Restart all three existing nodes in a sequence. > >> > >> 2. Replicate the new existing zoo.cfg to two new ensemble > >> Start Zookeeper on two new server > >> > >> > >> You can do this in backward sequence (0 -> 2 -> 1) > >> In your case, you can do 0 -> 2 -> 1, I think. > >> > >> Chang > >> > >> > >> > >> 2011. 5. 5., 오후 9:57, Jared Cantwell 작성: > >> > >> > It would be acceptable to me to do this non-dynamically and > non-rolling > >> as > >> > well. For example, I can shut down all nodes, make necessary > >> modifications > >> > to config files, and then restart all nodes. If I do this, should > >> switching > >> > from standalone mode to multi-node mode work? Has anyone done this > >> before? > >> > Preliminary tests seem to work, but I haven't looked into all the race > >> > conditions and such yet. > >> > > >> > ~Jared > >> > > >> > On Thu, May 5, 2011 at 12:02 AM, Alexander Shraer < > [email protected] > >> >wrote: > >> > > >> >> Hi Jared, > >> >> > >> >> Currently there is no support for adding and removing zookeeper nodes > >> >> dynamically. See: > >> >> https://issues.apache.org/jira/browse/ZOOKEEPER-107 > >> >> > >> >> We're currently working to add this feature. However, AFAIK there is > no > >> >> intention to support > >> >> transformation between standalone and multi-node modes, only > membership > >> >> changes in multi-node mode. > >> >> > >> >> Regards, > >> >> Alex > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: Jared Cantwell [mailto:[email protected]] > >> >>> Sent: Wednesday, May 04, 2011 7:17 PM > >> >>> To: [email protected] > >> >>> Subject: Growing a cluster > >> >>> > >> >>> Hello, > >> >>> > >> >>> Say I was going to grow a cluster from 1 node to 3 nodes. Is this > >> >>> possible, > >> >>> and what would be the recommended way? > >> >>> > >> >>> At first I was thinking that I could go from 1 to 2 and then 2 to 3, > >> >>> and it > >> >>> seems to be working actually. But I'm not sure if this is > supported, > >> >>> mostly > >> >>> because in standalone mode the on-disk files are different than they > >> >>> are in > >> >>> a multi-node configurations. Mutli-node configurations embed the > >> >>> quorum > >> >>> incarnation into the filename, which standalone does not. Should a > >> >>> quorum > >> >>> node be able to startup using snapshots and logs that a standalone > node > >> >>> wrote out? Is there a way around this? > >> >>> > >> >>> Thanks, > >> >>> Jared > >> >> > >> > >> > > >
