[
https://issues.apache.org/jira/browse/HBASE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883652#action_12883652
]
stack commented on HBASE-50:
----------------------------
isSnapshot in HRI?
In zk, writeZnode and readZnode ain't the best names for methods... what kinda
znodes are these? (Jon says these already exist, that they are not your fault)
Can you make a SnapShot class into which encapsulate all related to
snapshotting rather than adding new data members to HMaster? Maybe you do
encapsulate it all into snapshotmonitor? Maybe you do. And all I'm seeing are
the HMaster methods you need to add.
Can you call RSSnapshotHandler just SnapshotHandler?
Will keeping snapshot data in .META. work? .META. is by region but regions are
deleted after a split but you want your snapshot to live beyond this?
You probably don't need to support String overloads.
Your implemenation plan looks excellent.
> Snapshot of table
> -----------------
>
> Key: HBASE-50
> URL: https://issues.apache.org/jira/browse/HBASE-50
> Project: HBase
> Issue Type: New Feature
> Reporter: Billy Pearson
> Assignee: Li Chongxin
> Priority: Minor
> Attachments: HBase Snapshot Design Report V2.pdf, HBase Snapshot
> Design Report V3.pdf, HBase Snapshot Implementation Plan.pdf, Snapshot Class
> Diagram.png
>
>
> Havening an option to take a snapshot of a table would be vary useful in
> production.
> What I would like to see this option do is do a merge of all the data into
> one or more files stored in the same folder on the dfs. This way we could
> save data in case of a software bug in hadoop or user code.
> The other advantage would be to be able to export a table to multi locations.
> Say I had a read_only table that must be online. I could take a snapshot of
> it when needed and export it to a separate data center and have it loaded
> there and then i would have it online at multi data centers for load
> balancing and failover.
> I understand that hadoop takes the need out of havening backup to protect
> from failed servers, but this does not protect use from software bugs that
> might delete or alter data in ways we did not plan. We should have a way we
> can roll back a dataset.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
