Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 16 Feb 2012 22:43:00 +0000 (UTC)
From: "Amitanand Aiyer (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <420767299.48568.1329432180624.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1983804839.47302.1329419219510.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5414) Assign different memstoreTS to
 different KV's in the same WALEdit during replay
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209838#comment-13209838 ] 

Amitanand Aiyer commented on HBASE-5414:
----------------------------------------

There seem to be 3 approachs we can take in terms of how we split the WALEdit into different batch of mutations (with same memstoreTS).

Option (i): Current approach. Split when we see a change in KV's type (Delete --> Put, or Put --> Delete). 
 
   Not very accurate. We might combine multiple Put mutations into one mutation. But, this should be relatively insignificant.

Option (ii): Split per KV. Give a different memstoreTS to each KV.

   We might be splitting a single mutation into multiple parts. But, this should not be a problem. No readers start until the replay is done.

Option (iii): Find a way to mark the exact boundary. 
   Will entail inserting a "dummy/sentinel" KV into the WALEdit to represent the boundary. 
                
> Assign different memstoreTS to different KV's in the same WALEdit during replay
> -------------------------------------------------------------------------------
>
>                 Key: HBASE-5414
>                 URL: https://issues.apache.org/jira/browse/HBASE-5414
>             Project: HBase
>          Issue Type: Sub-task
>          Components: client, coprocessors, regionserver
>            Reporter: Amitanand Aiyer
>             Fix For: 0.94.0
>
>         Attachments: HBASE-5414.D1749.1.patch
>
>
> HBASE-5203 combines all the different Puts/Deletes into one WALEdit. This is
> required to ensure that we persist the atomic mutation in its enterity and not
> in parts.
> When combined into a single WALEdit, we create one big familyMap that is a combination
> of all the family maps in the mutations. The KV's in this familyMap have no information
> about memstoreTS (it is not yet assigned).
> However, when we apply the mutations to the Memstore (if there are no failures) we end up
> incrementing the memstoreTS for each operation. 
> This can lead to the client seeing different order of operations -- depending on weather or
> not there was a RS crash/restart.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira