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 01808F9BC for ; Fri, 5 Jul 2013 16:33:56 +0000 (UTC) Received: (qmail 79981 invoked by uid 500); 5 Jul 2013 16:33:55 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 79917 invoked by uid 500); 5 Jul 2013 16:33:55 -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 79905 invoked by uid 99); 5 Jul 2013 16:33:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jul 2013 16:33:54 +0000 X-ASF-Spam-Status: No, hits=1.0 required=5.0 tests=FORGED_YAHOO_RCVD,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [77.238.189.213] (HELO nm3-vm0.bullet.mail.ird.yahoo.com) (77.238.189.213) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 05 Jul 2013 16:33:49 +0000 Received: from [77.238.189.56] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 05 Jul 2013 16:33:27 -0000 Received: from [46.228.39.75] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 05 Jul 2013 16:33:27 -0000 Received: from [127.0.0.1] by smtp112.mail.ir2.yahoo.com with NNFMP; 05 Jul 2013 16:33:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373042007; bh=NjaBDBMSIX2poO4PS3khmgLeI69a12LkHVUm+wrfp3U=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=pLPANm9NP6nBFnXH8raTiDaGafcH2ukQ7QXrewA479eXUjvDMhAC0IH0qWO+Qenpx9KWYxR3lRPL4f4rfTB6nO0RpmuRA3rjqF2tDUBciWvDi9lyyklOWbkE4y5IJLLR7MndIcsvQ4x6sv5XvDmbkc4bT+hcrhK/MbKwAPY6+YI= X-Yahoo-Newman-Id: 367357.74019.bm@smtp112.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3c57Vz0VM1nIt23HFXSbA3xNX1j.f_F0JUO.LSUqAWfgwXd O3APMQvUji32fc2HdqyG3K64W_Zzl9iezMPKstrY1oA6W6S3_0lEkcBuEu5q yL.57wYKdoCcdhbKfW4i7PhZjRtfgxbzEPP_5t6fExA2p_bkTLCRi4g4SkkM qy2LzRtLKLAK5tA8i3rxoop0Vj.W3uLscWrfG9T8UY186Aybl5idq4mIyg.L yXBJjdLVTpy9TP5tSGbW5zuJ_.dhoA7TgvcgCWY0CCuo4YF9_gPYdNeiyzzC Arg3RS9T1vd7g6DJn10TAwKB5gWVODM9yjuUeSAj4hFPW4ovnD47u6sX.9yE b1T6BIly4U5SBOfDoiKZGlw6vHqVH.CTNlpk34.xnRlBS7gDDewXfi1LXqn1 RuIcxudhODE2nSjkmfgzVHtPB9_QniHuRqi69HLvdM1Fx.R2uT5_Fg44ghLH F9CchCfupUnprdsmsJBhZ.3R8iXel.iHzKbbrNGqrLcFY3HHrn_iqWeTgdKX fcqndFTRs2iysDdktBUXElCstm1Zh2bQpLgMuN8YKukncu7pqhd70WNvbGaf bNr7J1Cvepc_wAuOOUzGFspjiA8TfS1EPgEJgQ4dt X-Yahoo-SMTP: HT5UJDeswBACWJPOeualxAa.da..S.fl X-Rocket-Received: from MSRC4018287 (fpjunqueira@94.245.87.236 with ) by smtp112.mail.ir2.yahoo.com with SMTP; 05 Jul 2013 16:33:27 +0000 UTC From: "Flavio Junqueira" To: References: <017d01ce7984$06c74650$1455d2f0$@yahoo.com> In-Reply-To: Subject: RE: Backup/restore of an emsemble Date: Fri, 5 Jul 2013 17:33:26 +0100 Message-ID: <019401ce799d$60440560$20cc1020$@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFcLC9kaXimnBB0xBt2pKkP3tPuHgHnPMpIAlROFu+aGQWOwA== Content-Language: en-gb X-Virus-Checked: Checked by ClamAV on apache.org In your approach, would you "lock" the zookeeper state and read the data tree using getData/getChildren? If you have concurrent updates, then you may end up having an inconsistent snapshot. -Flavio -----Original Message----- From: Sergey Maslyakov [mailto:evolvah@gmail.com] Sent: 05 July 2013 17:12 To: user@zookeeper.apache.org Subject: Re: Backup/restore of an emsemble Yes, Flavio, I looked at Exhibitor, but I need a pretty granular control over a cluster of ZK servers. This is why I'm inclined to build something by hand. So far, a pair of external export and import clients seems like a promising approach. Export would connect to the ensemble and dump out the data into a file on disk. Import would connect, wipe out the namespace, and then reload the data from the file that was earlier created by the export client. On Fri, Jul 5, 2013 at 8:31 AM, Flavio Junqueira wrote: > Sergey, > > Have you had a look at Exhibitor? > > https://github.com/Netflix/exhibitor > > -Flavio > > -----Original Message----- > From: Sergey Maslyakov [mailto:evolvah@gmail.com] > Sent: 05 July 2013 04:39 > To: user@zookeeper.apache.org > Subject: Backup/restore of an emsemble > > A while ago, Jack Ma asked this question: > > http://mail-archives.apache.org/mod_mbox/zookeeper-user/201306.mbox/%3 > CCAB%2 > BcfdyPDpbUh5FyDT%3D9mU%3DFCHEA1AZpkF6X0nN1t4mjwqu2tA%40mail.gmail.com% > 3E > > I wonder if there were any helpful suggestions that did not go into > the mailing list. > > I am mostly concerned about restoring data in a Zookeeper ensemble. > > There is no document at the project web-site that would explain the > restore procedure for a distributed deployment. The home-grown > solution that involves stopping the whole cluster, wiping out > databases on all but one server, restoring the database on one server, > and then bring up the cluster and pray that the populated server > becomes the leader and populates the cluster. Such solution seems to be too error-prone. > > Does anyone have recommendations on how to make it robust? > > Maybe there is a way to force-populate the ensemble remotely? > > > Thanks, > /Sergey > >