Return-Path: Delivered-To: apmail-hbase-user-archive@www.apache.org Received: (qmail 54194 invoked from network); 3 Mar 2011 17:10:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Mar 2011 17:10:08 -0000 Received: (qmail 39100 invoked by uid 500); 3 Mar 2011 17:10:07 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 39050 invoked by uid 500); 3 Mar 2011 17:10:07 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 39042 invoked by uid 99); 3 Mar 2011 17:10:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Mar 2011 17:10:07 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=FREEMAIL_FROM,FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of billgraham@gmail.com designates 209.85.215.41 as permitted sender) Received: from [209.85.215.41] (HELO mail-ew0-f41.google.com) (209.85.215.41) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Mar 2011 17:09:59 +0000 Received: by ewy10 with SMTP id 10so560998ewy.14 for ; Thu, 03 Mar 2011 09:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=fONq4H9aSJsBxCnhU/UcrP1k5EZz0FEo3GKhFGAawMQ=; b=tbYfJIpbc67JQO8K7cZB04WN0CxrfMITjNannIV+m33fixFjU1INQfnfgrOq6uJUIw cEg3A8Y2rx/GM42raZFYCRMKpfd8DGjEYx9rARJ+ZgItZWf2cXVyJi9xt4Lns3q9ZrCA lRxJvUp1ESDwGOYGisr8So/JUQYSJswmicx8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; b=ZcGDQSoGULr0V+AcqGuO+tO2mIbNr4G8h6eCW+h6ChasCUMQcm/hql65ybg1rRr1Mt q289KXxvlZtDkUMbM2eSpOspdS46eAjl63vz0R2KHRyd/7IzRtKAIcd3Ib24GqCSW7vP Eg2Xt9h80rqqLCOfMaTyh8O3yN0nhFItO3Wvo= Received: by 10.216.67.80 with SMTP id i58mr1159168wed.28.1299172057125; Thu, 03 Mar 2011 09:07:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.53.77 with HTTP; Thu, 3 Mar 2011 09:07:17 -0800 (PST) Reply-To: billgraham@gmail.com In-Reply-To: References: <960571.66715.qm@web130123.mail.mud.yahoo.com> <110964.55057.qm@web130109.mail.mud.yahoo.com> <752022.72503.qm@web130103.mail.mud.yahoo.com> From: Bill Graham Date: Thu, 3 Mar 2011 09:07:17 -0800 Message-ID: Subject: Re: Questions about HBase Cluster Replication To: user@hbase.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org One more question for the FAQ: 6. Is it possible for an admin to tell just how out of sync the two clusters are? Something like Seconds_Behind_Master in MySQL's SHOW SLAVE STATUS? On Wed, Mar 2, 2011 at 9:32 PM, Jean-Daniel Cryans wr= ote: > Although, I would add that this feature is still experimental so who know= s :) > > I think the worst that happened to us was that replication was broken > (see the jira where if the master loses it's zk session with the slave > zk ensemble, it requires a HBase restart on the master side) for a few > days because of maintenance of the link between the two datacenters > which took more than a minute. When we finally did restart the master > cluster, it had to process about 2TBs of HLogs... those ICVs can > really generate a lot of data! > > J-D > > On Wed, Mar 2, 2011 at 9:25 PM, Jean-Daniel Cryans = wrote: >>> 5. If one is adding replication on the *production* Master cluster, wha= t's the >>> worst thing that can happen to this Master cluster? =A0Nothing scary ot= her than >>> changing configs + interruption during a restart? (which is currently s= till bad >>> because of region assignments?) >>> >> >> The replication code is pretty much encapsulated from the rest of the >> region server code, it won't mess with your Puts or change your >> birthday date. >> >> With 0.90 the regions are reassigned where they were before, so it's >> really just the block cache that gets screwed. >> >> J-D >> >