[
https://issues.apache.org/jira/browse/HBASE-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979799#action_12979799
]
ryan rawson commented on HBASE-3021:
------------------------------------
this is because we previously needed to avoid having 2 KVs with the same
timestamp, otherwise we might read from the 'older' one with a smaller value
and affect counter values.
With the work on HBASE-2856 we wont have to do this anymore.
> Timestamp mismatch between WAL and MemStore for ICVs
> ----------------------------------------------------
>
> Key: HBASE-3021
> URL: https://issues.apache.org/jira/browse/HBASE-3021
> Project: HBase
> Issue Type: Bug
> Reporter: Jean-Daniel Cryans
> Priority: Minor
>
> We've been running replication for a little while now and the tool I wrote to
> verify replicated data (will be posted in HBASE-3013) works great, unless
> that data is counters. The reason is that in HRegion.incrementColumnValue we
> append to the WAL a KV with a timestamp that we're not reusing for the
> MemStore (since we do some processing on it in updateColumnValue), so the
> replicated KV is different and comparing sets of rows using time ranges
> usually fails because one row will almost surely be cut in half on the edges
> (at least this is what my testing shows).
> I guess this is also an issue on the slave cluster since if we don't want
> values on the same ts on the master cluster, why would we want it elsewhere?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
