hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5203) Fix atomic put/delete with region server failures.
Date Mon, 16 Jan 2012 00:09:40 GMT

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

Lars Hofhansl commented on HBASE-5203:

Agreed. #1 might actually be tricky if there are multiple Deletes in a row, because it is
not possible to tell from KVs in the WALEdit to tell when one Delete (or Put) ends and the
next one starts.

For Puts this does not matter as the KVs can all just be added to one Put operation. For Deletes,
however, that is not possible. But it should be possible for Deletes to group all version-deletes
and column-deletes together and handle family-deletes separately.

I think #1 is the only correct option.

> Fix atomic put/delete with region server failures.
> --------------------------------------------------
>                 Key: HBASE-5203
>                 URL: https://issues.apache.org/jira/browse/HBASE-5203
>             Project: HBase
>          Issue Type: Sub-task
>          Components: client, coprocessors, regionserver
>            Reporter: Lars Hofhansl
>             Fix For: 0.94.0
> HBASE-3584 does not not provide fully atomic operation in case of region server failures
(see explanation there).
> What should happen is that either (1) all edits are applied via a single WALEdit, or
(2) the WALEdits are applied in async mode and then sync'ed together.
> For #1 it is not clear whether it is advisable to manage multiple *different* operations
(Put/Delete) via a single WAL edit. A quick check reveals that WAL replay on region startup
would work, but that replication would need to be adapted. The refactoring needed would be
> #2 Might actually not work, as another operation could request sync'ing a later edit
and hence flush these entries out as well.

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