hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5203) Group atomic put/delete operation into a single WALEdit to handle region server failures.
Date Mon, 16 Jan 2012 16:26:41 GMT

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

jiraposter@reviews.apache.org commented on HBASE-5203:
------------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3510/#review4397
-----------------------------------------------------------



http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<https://reviews.apache.org/r/3510/#comment9917>

    What I meant was that if coprocessorHost == null, the for loop can be skipped.


- Ted


On 2012-01-16 07:58:33, Lars Hofhansl wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/3510/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2012-01-16 07:58:33)
bq.  
bq.  
bq.  Review request for hbase, Ted Yu and Michael Stack.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  Basically a rewrite (sorry about that) of HBASE-3485 "Allow atomic put/delete in one
call".
bq.  This makes this actually correct in the case of RegionServer failures (HBASE-3485 was
correct for all scenarios but RegionServer failures).
bq.  HRegion.mutateRow(...) now groups all edits into a single WALEdit and appends all edits
in one call. Only then are the memstore edits applied.
bq.  This is the first time that WALEdits can contain KVs from different types of operations.
So I also had to fix the replication code to understand that.
bq.  WAL recovery already handles this case.
bq.  
bq.  
bq.  This addresses bug HBASE-5203.
bq.      https://issues.apache.org/jira/browse/HBASE-5203
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/client/Delete.java
1231744 
bq.    http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
1231744 
bq.    http://svn.apache.org/repos/asf/hbase/trunk/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSink.java
1231744 
bq.    http://svn.apache.org/repos/asf/hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
1231744 
bq.  
bq.  Diff: https://reviews.apache.org/r/3510/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  * Tests added in HBASE-3485
bq.  * manual testing.
bq.  * getting a full test run right now
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Lars
bq.  
bq.


                
> Group atomic put/delete operation into a single WALEdit to handle 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
>            Assignee: Lars Hofhansl
>             Fix For: 0.94.0
>
>         Attachments: 5203.txt
>
>
> 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
non-trivial.
> #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

        

Mime
View raw message