[
https://issues.apache.org/jira/browse/HBASE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509005#comment-13509005
]
Matteo Bertozzi commented on HBASE-7245:
----------------------------------------
If we use ZooKeeper what happens when the user erase the zk content before
starting the master? we still have the bad state on disk and meta but no hint
on the unfinished operation.
If I understood correctly we are using zookeeper as "ephimeral" only (except
for replication) do we want to move to something that rely fully on zookeeper?
> Recovery on failed snapshot restore
> -----------------------------------
>
> Key: HBASE-7245
> URL: https://issues.apache.org/jira/browse/HBASE-7245
> Project: HBase
> Issue Type: Sub-task
> Components: Client, master, regionserver, snapshots, Zookeeper
> Reporter: Jonathan Hsieh
> Assignee: Matteo Bertozzi
> Fix For: hbase-6055, 0.96.0
>
>
> Restore will do updates to the file system and to meta. it seems that an
> inopportune failure before meta is completely updated could result in an
> inconsistent state that would require hbck to fix.
> We should define what the semantics are for recovering from this. Some
> suggestions:
> 1) Fail Forward (see some log saying restore's meta edits not completed, then
> gather information necessary to build it all from fs, and complete meta
> edits.).
> 2) Fail backwards (see some log saying restore's meta edits not completed,
> delete incomplete snapshot region entries from meta.)
> I think I prefer 1 -- if two processes end somehow updating (somehow the
> original master didn't die, and a new one started up) they would be
> idempotent. If we used 2, we could still have a race and still be in a bad
> place.
--
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
