[
https://issues.apache.org/jira/browse/HBASE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284532#comment-13284532
]
Jonathan Hsieh commented on HBASE-6055:
---------------------------------------
Jesse,
Thanks for the writeup, I find having a single doc with the design summary
really helpful and ideally something we do for all major new features. I've
read through the document carefully, let it steep for a few days, and had some
design-level questions. I've skimmed HBASE-50 and will read more of the
history more carefully later this evening.
What is the read mechanism for snapshots like? Does the snapshot act like a
read-only table or is there some special external mechanism needed to read the
data from a snapshot? You mention having to rebuild in-memory state by
replaying wals -- is this a recovery situation or needed in normal reads?
What is a representation of a snapshot look like in terms of META and file
system contents? At some point we may get called upon to repair these, I want
to make sure there are enough breadcrumbs for this to be possible.
I'm still thinking about the two-phase part -- I think it is necessary for
marking success or initiating failure recovery, but I'm skeptical at the moment
about why the barriering writes is necessary. How does this buy your more
consistency? Aren't we still inconsistent at the prepare point now instead?
Can we just write the special snapshotting hlog entry at initiation of prepare,
allowing writes to continue, then adding data elsewhere (META) to mark success
in commit? We could then have some compaction/flush time logic cleanup failed
atttempt markers?
> Snapshots in HBase 0.96
> -----------------------
>
> Key: HBASE-6055
> URL: https://issues.apache.org/jira/browse/HBASE-6055
> Project: HBase
> Issue Type: New Feature
> Components: client, master, regionserver, zookeeper
> Reporter: Jesse Yates
> Assignee: Jesse Yates
> Fix For: 0.96.0
>
> Attachments: Snapshots in HBase.docx
>
>
> Continuation of HBASE-50 for the current trunk. Since the implementation has
> drastically changed, opening as a new ticket.
--
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
