hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-10153) improve VerifyReplication to compute BADROWS more accurately
Date Fri, 03 Oct 2014 03:26:34 GMT

     [ https://issues.apache.org/jira/browse/HBASE-10153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ted Yu updated HBASE-10153:
    Release Note: 
VerifyReplicaiton reports the following counters besides the existing ones:

ONLY_IN_SOURCE_TABLE_ROWS: number of rows found only in source
ONLY_IN_PEER_TABLE_ROWS: number of rows found only in peer
CONTENT_DIFFERENT_ROWS: number of rows whose contents are different between source and peer

> improve VerifyReplication to compute BADROWS more accurately
> ------------------------------------------------------------
>                 Key: HBASE-10153
>                 URL: https://issues.apache.org/jira/browse/HBASE-10153
>             Project: HBase
>          Issue Type: Improvement
>          Components: Operability, Replication
>    Affects Versions: 0.94.14
>            Reporter: cuijianwei
>            Assignee: cuijianwei
>             Fix For: 2.0.0, 0.98.7, 0.99.1
>         Attachments: 10153-0.98.txt, 10153-v2-trunk.txt, HBASE-10153-0.94-v1.patch, HBASE-10153-trunk.patch
> VerifyReplicaiton could compare the source table with its peer table and compute BADROWS.
However, the current BADROWS computing method might not be accurate enough. For example, if
source table contains rows as {r1, r2, r3, r4} and peer table contains rows as {r1, r3, r4}
BADROWS will be 3 because 'r2' in source table will make all the later row comparisons fail.
Will it be better if the BADROWS is computed to 1 in this situation? Maybe, we can compute
the BADROWS more accurately in merge comparison?

This message was sent by Atlassian JIRA

View raw message