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: domain of tobeg3oogle@gmail.com
 designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <trinity-8eb92245-845f-4354-8228-74b25eda6f82-1409127956325@3capp-webde-bs38>
References: 
 <trinity-30c699ad-f0d8-480d-b6ea-13119af989e3-1409040605981@3capp-webde-bs08>
	<CAEf3A-xu-m_v0FC8pJ7_od+2n5L8BWHP+Y4RZA_cH__JSVazPA@mail.gmail.com>
	<trinity-78cd7f12-d5eb-4144-90a1-f5ba5bb8f742-1409048710139@3capp-webde-bs13>
	<CAEf3A-zbhVrybMnA=6n0NPmsqqFBTAqfjOSMZH2iDbxCXvNGNA@mail.gmail.com>
	<trinity-8eb92245-845f-4354-8228-74b25eda6f82-1409127956325@3capp-webde-bs38>
Date: Thu, 28 Aug 2014 09:06:05 +0800
Message-ID: 
 <CAEf3A-z5AKyaLwRfFqbjLHSksfxTeh9UvbmfvkUkDzU2nU98TQ@mail.gmail.com>
Subject: Re: Re: Re: Hbase verifyrep compares different key's
From: tobe <tobeg3oogle@gmail.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=089e0158c51616a8180501a62478

--089e0158c51616a8180501a62478
Content-Type: text/plain; charset=UTF-8

Yes, you're right. After applying that patch, a little inconsistency is
acceptable, but not like what you saw before.
 Actually now we count ONLY_IN_SOURCE_TABLE_ROWS, ONLY_IN_PEER_TABLE_ROWS
and CONTENT_DIFFERENT_ROWS rather than just BADROWS.


On Wed, Aug 27, 2014 at 4:25 PM, Hansi Klose <hansi.klose@web.de> wrote:

> Hi tobe,
>
> yes we are replicating during verify.
>
> So as I understand, the problem is that during the verify job the one key
> is updated (with new timestamp)
> while this key will be verified. So on one side the key timestamp is in
> the verify timerange but on the
> other side no more. So the key is "missing" there and the next key will be
> compared.
>
> Maybe I am totally wrong and someone has a good description of what
> happens ;-)
>
> Regards Hansi
>
> > Gesendet: Dienstag, 26. August 2014 um 13:22 Uhr
> > Von: tobe <tobeg3oogle@gmail.com>
> > An: "user@hbase.apache.org" <user@hbase.apache.org>
> > Betreff: Re: Re: Hbase verifyrep compares different key's
> >
> > @hansi Are you running replication or updating data during verification?
> If
> > so, a little inconsistency is reasonable because the replication is final
> > consistent.
> >
> > But if you compare these two cluster which will not update, you should
> not
> > get BADROWS. This tool is well for static comparison.
> >
> >
> > On Tue, Aug 26, 2014 at 6:25 PM, Hansi Klose <hansi.klose@web.de> wrote:
> >
> > > Hi Tobe,
> > >
> > > ok, this is why there are so many, but this means that in the job with
> > > BADROWS
> > > there is minimum one row missing at that time on one side.
> > >
> > > Right?
> > >
> > > Regards Hansi
> > >
> > > > Gesendet: Dienstag, 26. August 2014 um 10:20 Uhr
> > > > Von: tobe <tobeg3oogle@gmail.com>
> > > > An: "user@hbase.apache.org" <user@hbase.apache.org>
> > > > Betreff: Re: Hbase verifyrep compares different key's
> > > >
> > > > It's the bug of VerifyReplication, please refer to [HBASE-10153]
> > > > <https://issues.apache.org/jira/browse/HBASE-10153>.
> > > >
> > > > Need someone to review and fix it.
> > > >
> > > >
> > > > On Tue, Aug 26, 2014 at 4:10 PM, Hansi Klose <hansi.klose@web.de>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I run periodically verify jobs on our hbase tables.
> > > > > One some tables i have problems with many BADROWS.
> > > > >
> > > > > I looked into the job log file and recognized that
> > > > > the job started to compare different key.
> > > > >
> > > > > I looks like the job missees on key on one the replication target
> side
> > > > > and from that point each key in that job produces BADROWS.
> > > > >
> > > > > Like this:
> > > > >
> > > > > A - A
> > > > > B - B
> > > > > C -
> > > > > D - C
> > > > > E - D
> > > > > F - E
> > > > >
> > > > > Even when I go 3 days back with my --starttime and --endtime
> > > > > I have this problem too.
> > > > >
> > > > > I do not really understand why that happens.
> > > > >
> > > > > The hbase tables have a high volume of write action.
> > > > >
> > > > > We use Hbase 0.94.2-cdh4.2.0.
> > > > >
> > > > > Regards Hans
> > > > >
> > > >
> > >
> >
>

--089e0158c51616a8180501a62478--