Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E10C3F509 for ; Tue, 7 May 2013 22:35:17 +0000 (UTC) Received: (qmail 85200 invoked by uid 500); 7 May 2013 22:35:16 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 85159 invoked by uid 500); 7 May 2013 22:35:16 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 85119 invoked by uid 99); 7 May 2013 22:35:16 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 May 2013 22:35:16 +0000 Date: Tue, 7 May 2013 22:35:16 +0000 (UTC) From: "Jean-Daniel Cryans (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (HBASE-3021) Timestamp mismatch between WAL and MemStore for ICVs MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Daniel Cryans resolved HBASE-3021. --------------------------------------- Resolution: Invalid Not sure what the current situation is now but this is too old to be useful. > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira