Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=received:user-agent:date:subject:from:to:message-id:
	thread-topic:thread-index:in-reply-to:mime-version:content-type:
	content-transfer-encoding:x-originalarrivaltime;
	b=L7Vc+k04vYkOoZXhd8Ft/uu/xiFyVYmvob94+OmEiUw0BI2dKiG1eY0o9KqHmGsW
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Mon, 04 May 2009 14:35:08 -0700
Subject: Re: Moving ZooKeeper Servers
From: Mahadev Konar <mahadev@yahoo-inc.com>
To: <zookeeper-user@hadoop.apache.org>
Message-ID: <C624AD9C.1C205%mahadev@yahoo-inc.com>
Thread-Topic: Moving ZooKeeper Servers
Thread-Index: AcnNADIKVrKMMm9XVkiMcAcNXGCmig==
In-Reply-To: <c7d45fc70905041110i1fe5f579y568b12a9061603cd@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Satish,
  Is the re generation of state in production something that is not
acceptable? Copying over the whole datadir and datalogdir as it is
maintaining the dirctory structure would be necessary.

Also, in general this is a bad idea (just to warn you) since you would have
to be careful with data copying ( making sure that their is one to one
mapping between the data copying from pre prod to prod)-- meaning

Pre prod1 -> prod1 (copying from pre prod1 to prod 1)
Pre prod2 -> prod2 (copy from pre prod 2 to prod 2).

The one to one mapping is essential to make sure data isnt lost.

Also, you have to make sure htat you have a clean database in prod1 and you
do not have files in production that overlaps old file from production and
the new files you copied over from pre production. This will cause database
corruption since you will have an overlap of database from pre prod and old
production.

So, zookeeper would work fine if you are careful with above but I would vote
against doing this for production since the above is pretty easy to mess up.

mahadev


On 5/4/09 11:10 AM, "Ted Dunning" <ted.dunning@gmail.com> wrote:

> I think it would be easier to add the production machines to the cluster one
> by one and then remove the pre-production ZK instances from the cluster one
> by one.
> 
> This gives you continuity that you lack otherwise.  Adding machines is a
> matter of changing the configuration on each ZK and restarting ZK on that
> machine.  You could add the machines in a lump if you don't add so many as
> to prevent the cluster from having a quorum.  The configuration change and
> restart can be easily scripted and goes quite quickly.
> 
> After the hand-off, you can bring the pre-production machines machines back
> up with a smaller cluster configuration.
> 
> Of course, this trick only works if you have no production ZK already in
> place so it won't work the second time around.  It is also a bit unusual for
> the complete state of a pre-production staging cluster to be important
> enough to preserve.
> 
> On Mon, May 4, 2009 at 10:35 AM, Satish Bhatti <cthd2001@gmail.com> wrote:
> 
>> ... (2) At some point, we want to switch the preproduction instance to be
>> the
>> production instance.  For the ZooKeeper servers, we will copy the data +
>> logs directories from the pre machines currently running ZooKeeper to the
>> prod machines that will be running ZooKeeper, and start up ZooKeeper on
>> those machines.  Is this all that is necessary so that the new ZooKeeper
>> cluster effectively continues from where the pre cluster left off?  Am I
>> missing something?
>> 
>> --
> Ted Dunning, CTO
> DeepDyve