Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=uR2CoCEiqm1xqB9G3xbL759/0YDLb7Y+d9udG8Nza6c6zRAcdS4pUGv6O3yHYXiMxyyFCAmOSU1z+aVZoHU6iSYDS5Gky6zBCM8Ae46r4LnXU5AmQ2BgK3zpeb/4TUsQKxdhmUyK9WF5rwOlMAt+pTS5XYl640ivkGr8wjyaPp0=;
Message-ID: <491797.489.qm@web130107.mail.mud.yahoo.com>
References: <960571.66715.qm@web130123.mail.mud.yahoo.com>
 <AANLkTinLQU8R5=r0J69dLdmFA1rNCkBwugAUaKFEt6ck@mail.gmail.com>
 <110964.55057.qm@web130109.mail.mud.yahoo.com>
 <752022.72503.qm@web130103.mail.mud.yahoo.com>
 <AANLkTimP5h-hsWjHuQuzAX6cjcZYh+mhBVGG8FGQTFbO@mail.gmail.com>
 <AANLkTimJ8mraeMgOQPrCE8gPMeO0n+utDM__=nu=WM6e@mail.gmail.com>
 <AANLkTinXQr0cd947pcSHDkfKLhpe-zNx0Wzrh4YDtMka@mail.gmail.com>
 <AANLkTimhR5oSNSwsv5gbDwM01rfn-3GJxoNwR9usGGJc@mail.gmail.com>
 <AANLkTiko4k47Xnmi2jkfQZW4kfyy4_v-E1qBvYyM3P3N@mail.gmail.com>
 <409853.12725.qm@web130104.mail.mud.yahoo.com>
 <AANLkTimgtpbFzU56+tzc1EmQKjFaDyqJcnrNyEs_m2-e@mail.gmail.com>
Date: Thu, 3 Mar 2011 12:10:01 -0800 (PST)
From: Otis Gospodnetic <otis_gospodnetic@yahoo.com>
Subject: Re: Questions about HBase Cluster Replication
To: user@hbase.apache.org
In-Reply-To: <AANLkTimgtpbFzU56+tzc1EmQKjFaDyqJcnrNyEs_m2-e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Aha, so the fact that the age doesn't change when replication keeps retrying is 
really a bug?

Otis


----- Original Message ----
> From: Jean-Daniel Cryans <jdcryans@apache.org>
> To: user@hbase.apache.org
> Sent: Thu, March 3, 2011 2:17:08 PM
> Subject: Re: Questions about HBase Cluster Replication
> 
> No it's the age in ms:
> 
> ageOfLastAppliedOp.set(System.currentTimeMillis()  - timestamp);
> 
> And the timestamp is the one given to the HLogEdit, not the  timestamp
> of the cell.
> 
> J-D
> 
> On Thu, Mar 3, 2011 at 11:13 AM,  Otis Gospodnetic
> <otis_gospodnetic@yahoo.com>  wrote:
> > Is that really the *age* really the *timestamp* of last  successful log 
>shipment?
> > If so, one could calculate the real age with  age = now() -
> > ageOfLastShippedOnWhichIsReallyTimestamp .  And that would  be useful to 
>have.
> >
> > Otis
> > ----
> > Sematext :: http://sematext.com/ :: Solr -  Lucene - Nutch
> > Lucene ecosystem search :: http://search-lucene.com/
> >
> >
> >
> > ----- Original  Message ----
> >> From: Jean-Daniel Cryans <jdcryans@apache.org>
> >> To: user@hbase.apache.org
> >> Sent:  Thu, March 3, 2011 12:21:09 PM
> >> Subject: Re: Questions about HBase  Cluster Replication
> >>
> >> It's a work in progress, that  information is currently published by
> >> every  region server in the  master cluster (since it's push
> >> replication, not pull)  through JMX  under the name
> >> "ageOfLastShippedOp". It's really not perfect   though, since if it
> >> fails to replicate and starts retrying then the  age won't  change but
> >> the actual lag will go up. Also it will have  to be revisited when  we
> >> add multiple slaves since you don't really  want to publish the  same
> >> metric for multiple slaves... it really  wouldn't  work.
> >>
> >> J-D
> >>
> >> On Thu, Mar  3, 2011 at 9:10 AM, Bill Graham <billgraham@gmail.com>  wrote:
> >> >  Actually, how far behind replication is w.r.t. edit  logs is different
> >> >  than how out of sync they are, but you get  the idea.
> >> >
> >> > On Thu, Mar  3, 2011 at 9:07 AM,  Bill Graham <billgraham@gmail.com>  
> wrote:
> >> >> 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 
><jdcryans@apache.org>
> >>wrote:
> >>  >>> Although, I would add that this feature is still  experimental so  who 
>knows
> >>:)
> >> >>>
> >> >>> 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 
><jdcryans@apache.org>
> >>wrote:
> >>  >>>>> 5. If one is adding replication on the  *production*  Master 
cluster,
> >>what's the
> >> >>>>> worst  thing that  can happen to this Master cluster?  Nothing scary  
>other
> >>than
> >> >>>>> changing configs +  interruption during a restart?  (which is 
>currently
> >>still  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
> >> >>>>
> >> >>>
> >>  >>
> >> >
> >>
> >
>