[
https://issues.apache.org/jira/browse/HBASE-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-7346:
----------------------------------
Issue Type: Test (was: Sub-task)
Parent: (was: HBASE-6055)
> Restored snapshot replay problem
> --------------------------------
>
> Key: HBASE-7346
> URL: https://issues.apache.org/jira/browse/HBASE-7346
> Project: HBase
> Issue Type: Test
> 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
