[
https://issues.apache.org/jira/browse/HBASE-16423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423733#comment-15423733
]
Jianwei Cui commented on HBASE-16423:
-------------------------------------
[~churromorales], there are cases will change the versions between [startTime,
endTime) during VerifyReplication scanning. For example, if there are new
versions being written to source cluster, the total versions may exceed the
family max version so that compaction will cause the versions between
[startTime, endTime) deleted, the compaction may happen at different time in
source and peer clusters, making VerifyReplication may report inconsistent
rows.
> Add re-compare option to VerifyReplication to avoid occasional inconsistent
> rows
> --------------------------------------------------------------------------------
>
> Key: HBASE-16423
> URL: https://issues.apache.org/jira/browse/HBASE-16423
> Project: HBase
> Issue Type: Improvement
> Components: Replication
> Affects Versions: 2.0.0
> Reporter: Jianwei Cui
> Priority: Minor
>
> Because replication keeps eventually consistency, VerifyReplication may
> report inconsistent rows if there are data being written to source or peer
> clusters during scanning. These occasionally inconsistent rows will have the
> same data if we do the comparison again after a short period. It is not easy
> to find the really inconsistent rows if VerifyReplication report a large
> number of such occasionally inconsistency. To avoid this case, we can add an
> option to make VerifyReplication read out the inconsistent rows again after
> sleeping a few seconds and re-compare the rows during scanning. This behavior
> follows the eventually consistency of hbase's replication. Suggestions and
> discussions are welcomed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
