hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ryan rawson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3021) Timestamp mismatch between WAL and MemStore for ICVs
Date Mon, 10 Jan 2011 22:11:48 GMT

    [ 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.


Mime
View raw message