[
https://issues.apache.org/jira/browse/HBASE-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529155#comment-13529155
]
Jonathan Hsieh commented on HBASE-7290:
---------------------------------------
It is not a concurrency problem at that granularity.
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.
> Online snapshots
> -----------------
>
> Key: HBASE-7290
> URL: https://issues.apache.org/jira/browse/HBASE-7290
> Project: HBase
> Issue Type: Bug
> Reporter: Jonathan Hsieh
>
> HBASE-6055 will be closed when the offline snapshots pieces get merged with
> trunk. This umbrella issue has all the online snapshot specific patches.
> This will get merged once one of the implementations makes it into trunk.
> Other flavors of online snapshots can then be done as normal patches instead
> of on a development branch.
--
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
