Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CF5B0584D for ; Thu, 12 May 2011 13:55:01 +0000 (UTC) Received: (qmail 52329 invoked by uid 500); 12 May 2011 13:55:01 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 52291 invoked by uid 500); 12 May 2011 13:55:01 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 52283 invoked by uid 99); 12 May 2011 13:55:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 May 2011 13:55:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of vishalmlst@gmail.com designates 209.85.215.170 as permitted sender) Received: from [209.85.215.170] (HELO mail-ey0-f170.google.com) (209.85.215.170) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 May 2011 13:54:53 +0000 Received: by eyf5 with SMTP id 5so572349eyf.15 for ; Thu, 12 May 2011 06:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zScyMjgiGZoQVuW72Bq61oj3SLNLnTncki8ELRZ0UwU=; b=Lp7wd+zSGEv4dMGA6gh7tLEGo7MPNk5OWMQ4qVVrvWuEAeQzpi4QHguy5LXsnz0PiG NP2f8E5K6ZoZ+PlRpg+wKV9Y1vEvmEN45Ox7cuBnAlGL8J/nzjZCBUTT/jxuVkpZxMT6 TyvXGfckS8yO8nLOA3Klon3YlBg9SdFLa+KXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=M660/ALMPpWTAyslRZ0zbmhF1X4aS/u1c7IW12ZN45heE5GNv2BWwE6V2AoEnCSQHS Y0BYyJwwdPc38EHXQ3+Z9l07JCwkpeCat7Zn4Xd7Vk0SQFIRahM1R2ypzu0FgTQZGiZK E+t3ciLjiymJreBu6RcZ0RySkmSwq6v9P/YeY= MIME-Version: 1.0 Received: by 10.14.16.104 with SMTP id g80mr108913eeg.22.1305208473004; Thu, 12 May 2011 06:54:33 -0700 (PDT) Received: by 10.14.37.137 with HTTP; Thu, 12 May 2011 06:54:32 -0700 (PDT) In-Reply-To: <22975.34233.qm@web137310.mail.in.yahoo.com> References: <774134.13077.qm@web137313.mail.in.yahoo.com> <22975.34233.qm@web137310.mail.in.yahoo.com> Date: Thu, 12 May 2011 09:54:32 -0400 Message-ID: Subject: Re: Changing hosts From: Vishal Kher To: user@zookeeper.apache.org, "Murali Krishna. P" Content-Type: multipart/alternative; boundary=0016e65a0db6642ef604a31487f3 X-Virus-Checked: Checked by ClamAV on apache.org --0016e65a0db6642ef604a31487f3 Content-Type: text/plain; charset=ISO-8859-1 Hi, Since you can stop clients, another way to achieve what Alex suggested is to: 1. stop clients 2. stop all current zk servers (a_i) 3. scp -r /etc/zookeeper/ from a_i to b_i 4. scp -r /var/zookeeper/ from a_i to b_i 5. On all b_i, edit /etc/zookeeper/zoo.cfg to reflect the correct IP addresses 5 start all b_i This is assuming that stopping ZK server is ok in our environment. -Vishal On Thu, May 12, 2011 at 2:07 AM, Murali Krishna. P wrote: > Thanks for the responses, > I have the luxury of stopping the clients during the operations. So, I > would go with the second approach of cloning. > > > Thanks, > Murali Krishna > > > ________________________________ > From: Ted Dunning > To: Alexander Shraer > Cc: "user@zookeeper.apache.org" ; Murali > Krishna. P ; "zookeeper-user@hadoop.apache.org" < > zookeeper-user@hadoop.apache.org> > Sent: Thursday, 12 May 2011 5:27 AM > Subject: Re: Changing hosts > > > Alex, > > I think that this process does a slightly different thing. Your process is > good for cloning a cluster, but it doesn't address the problem of > transitioning a working cluster. My process never has two clusters with the > same data so all transactions will always be applied to a single notional > version of the data. > > The reason that this is important is a part of the process that neither of > us mentioned. That is how to transition the clients. My assumption is that > before the transition, all clients would re-open their ZK connection with > all 6 nodes in the list of servers. Once this is done, my process will lead > the clients through the transition in a way that all updates will be visible > to all clients. At the end, the clients should (eventually) trim their list > of servers to the shorter list of new servers. > > With a cluster clone operation, there will be moments when some clients > connect to one cluster and some connect to the other. That makes it hard to > understand how this will work well. > > The OP can probably clarify which task they really wanted to accomplish. > > > > > On Wed, May 11, 2011 at 4:49 PM, Alexander Shraer > wrote: > > Hi Ted, > > > >There's a simpler way that works. Suppose that the original servers are A, > B and C, and the new ones > >are D, E, F. Configure D, E and F to be in the configuration A, B, C, D, > E, F and start them. Don't do any changes to > >A, B and C. After D, E and F synch with the leader (or at least 2 of them > do), turn them off, change their config files to D, E, F and bring them up > again. > > > >Alex > > > > > > > > > > > >> -----Original Message----- > >> From: Ted Dunning [mailto:ted.dunning@gmail.com] > >> Sent: Tuesday, May 10, 2011 8:39 AM > >> To: user@zookeeper.apache.org; Murali Krishna. P > >> Cc: zookeeper-user@hadoop.apache.org > >> Subject: Re: Changing hosts > >> > >> Step 1: configure two of the new hosts to be part of a 5 node cluster > >> containing all of the > >> original nodes. > >> > >> Step 2: reconfigure each of the original 3 nodes to be part of the the > >> 5 > >> node cluster. > >> > >> Step 3: bounce each of the originals and start the two new servers. > >> > >> Step 4: configure the 6th server (previously untouched) to be part of a > >> three node cluster > >> containing only the 3 new nodes. > >> > >> Step 5: reconfigure servers 4 and 5. > >> > >> Step 6: bounce servers 4 and 5 and start server 6. > >> > >> Done. > >> > >> (wait for somebody else to critique this procedure before proceeding > >> with > >> it) > >> > >> On Tue, May 10, 2011 at 7:54 AM, Murali Krishna. P > >> wrote: > >> > >> > Hi, > >> > I have a zookeeper cluster (3.2.2) with 3 hosts. I need to > >> replace all > >> > the 3 hosts with different machines. What is the best way to achieve > >> this > >> > without any data loss? I can shutdown my clients during this > >> operation. > >> > > >> > > >> > > >> > Thanks, > >> > Murali Krishna > > > --0016e65a0db6642ef604a31487f3--