hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kannan Muthukkaruppan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5414) Assign different memstoreTS to different KV's in the same WALEdit during replay
Date Thu, 16 Feb 2012 19:58:59 GMT

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

Kannan Muthukkaruppan commented on HBASE-5414:


Aren't there three pieces of the puzzle to ensure that a atomic row mutation (RowMutations)
which contains a Delete & a Put, for example:

   RowMutations(Delete R1.CF         @ NOW,  // delete the row in this CF
                Put    R1.CF.c1 = v1 @ NOW)  // and atomically add back a column for this
row in this CF

can guarantee that the Put wins over the Delete even though both happened at the same NOW

part 1) On insert, making sure the Put gets a higher memstoreTS than the Delete even thought
they have the same TS.
part 2) On recovery (that's the piece that this JIRA seems to be covering).
part 3) On flush/compactions, etc. not doing the space optimization to clear out memstoreTS
to 0 even if the read point for the active scanners has moved on, unless it is a major compaction
where we lose the Delete markers.

Do we not need parts #1 & #3? Or where you planning to do those as separate tasks?

> 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
> incrementing the memstoreTS for each operation. 
> This can lead to the client seeing different order of operations -- depending on weather
> 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


View raw message