Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4D224F5A.604@demandware.com>
Date: Mon, 03 Jan 2011 17:36:10 -0500
From: Sergei Babovich <sbabovich@demandware.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
MIME-Version: 1.0
To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>
Subject: Re: DR policies/HA setup in production - best practices
References: <C9478E3E.492C4%mahadev@yahoo-inc.com>
In-Reply-To: <C9478E3E.492C4%mahadev@yahoo-inc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks a lot! Really helped!
On 01/03/2011 05:31 PM, Mahadev Konar wrote:
> Sergei,
>   I think Ted already answered you question but in case you are interested in
> more details, please take a look at
>
> http://hadoop.apache.org/zookeeper/docs/r3.2.1/zookeeperInternals.html
>
> Thanks
> mahadev
>
>
> On 1/3/11 1:43 PM, "Ted Dunning"<ted.dunning@gmail.com>  wrote:
>
>    
>> Actually, ZK is very good in this regard.
>>
>> The lifetime of a single leader is denoted by an epoch number.  Transactions
>> are identified by an epoch and a sequence number assigned by the leader.
>>   Since there is only one leader and because all transactions are executed
>> serially, this
>> combination of epoch and transaction id uniquely specifies a transaction and
>> provides a complete ordering.
>>
>> As transactions are committed, members of the committing quorum record the
>> latest epoch and transaction.
>>
>> When you restart a cluster, the members of the cluster negotiate to
>> determine who has the latest transaction and then start from there.  As
>> such, it is probably a good idea to backup more than just one log+snapshot
>> so that you have a better chance of having a later copy.
>>
>> On Mon, Jan 3, 2011 at 12:58 PM, Sergei Babovich
>> <sbabovich@demandware.com>wrote:
>>
>>      
>>> It is also understood about DR strategy. What is the mechanism for ZK to
>>> resolve conflicts in such case? Let's say we have a primitive backup
>>> strategy of shipping logs every hour. In theory it means (assuming the worst
>>> case) that on DR site all servers will have snapshots of the data made at
>>> different point in time. When I bring the DR cluster up what is a protocol
>>> of resolving inconsistencies? That was a reason of my question - it felt
>>> (may be naively) that recovering by replicating from the single node data
>>> (snapshot+log) would be safer and more consistent approach - it is easier to
>>> make guaranties about result.
>>>
>>>
>>>        
>>      
>    

This e-mail message and all attachments transmitted with it may contain privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message, all attachments and all copies and backups thereof.