hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7346) Restored snapshot replay problem
Date Thu, 13 Dec 2012 19:58:12 GMT

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

Jonathan Hsieh commented on HBASE-7346:
---------------------------------------

This crash I'm talking about is after the restore has successfully completed (after step 4).
 

Does the disable table flushing + log rolling guarantee that logs are moved out of the way
so that they won't be replayed?  

Let's double check and add a test case for this.  That is the easiest way to convince that
this is or isn't a problem on the offline or online cases.



                
> Restored snapshot replay problem
> --------------------------------
>
>                 Key: HBASE-7346
>                 URL: https://issues.apache.org/jira/browse/HBASE-7346
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Client, master, regionserver, snapshots, Zookeeper
>    Affects Versions: hbase-6055
>            Reporter: Jonathan Hsieh
>            Priority: Critical
>             Fix For: hbase-6055
>
>
> The situation is a coarse-grained problem. The key problem is that writes that shouldn't
be replayed (since they don't belong to the restored image), would not normally get replayed,
but would potentially get replayed if recovery was triggered.
> Previously, without restore, we could depend on the timestamps – if something was replayed
but there was newer data, the newer data would win. In a restore situation, the "newer" data
is has the old time stamps from before recovery, and new data that shouldn't get replayed
could be.
> ex: 
> 1) write 100 rows
> 2) ss1 (with logs)
> 3) write 50 rows
> 4) restore ss1
> 5) crash
> 6) writes from 1 and 3 both get replayed in log splitting recovery. Oops.

--
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

Mime
View raw message