[
https://issues.apache.org/jira/browse/HBASE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292952#comment-13292952
]
Matteo Bertozzi commented on HBASE-6055:
----------------------------------------
@Jon inline replies
{quote}
I issue a "snapshot" command at the shell/master.
* HBase creates a new .snapshot subdir, and it contains references to HLogs and
HFiles. This is a "snapshot"
** This step is called: snapshotting, "taking a snapshot", and also
materializing right?
{quote}
Yes, When you issue a "snapshot" command, hbase create a new .snapshot subdir
containing references to hlog and hfile.
This is "taking a snapshot" or snapshotting...
but not materialization, I think "materialization" is when you copy the
hfiles/hlogs somewhere else...
{quote}
I currently have a snapshot. I want read-only access its contents to compare
with the current table.
* Does HBase know how to interpret the stuff in a .snapshot dir such that it
act like a read-only table?
* Do I, as an admin, need to execute some step to make it appear in HBase as a
read-only table? (if so what is this called?)
{quote}
I think that the first point is more like a snapshot-scan... that scan the
hfiles + hlog in the snapshot directory and show you the result...
The second point seems more like a "Restore on different table" and marking the
table as readonly
{quote}
I currently have a snapshot. Oops! I accidentally truncated the table I had
snapshotted. I don't want the truncated version of the table anymore and I want
to replace the table with the snapshot so I have read write access.
* This is called "restoring" the snapshot right? (and I do this by issuing a
something like "restore" command at the shell?)
* Does HBase copy or move the data referred to in the snapshot?
{quote}
"Restore" is when you replace your current table with the snapshot version, and
you do it by "restore snapshot-name"
Yeah you need to copy the "old hfiles" to restore the snapshot (but maybe not
every hfiles are removed from the current table)
{quote}
I currently have a snapshot. I want the current version but I'd like to clone
of the snapshotted table that provides read/write access to the clone.
* Is/should this be supported?
* Is this called "restoring" or "exporting" the snapshot (to a new name)?
* For this to work I need to convert all references into actual copies of the
HFiles and HLogs right? Is this conversion called exporting? (FYI, this is what
I meant materializing to mean, but let's just stick to your definitions)
{quote}
Yeah this is really easy with HardLink... some more work is needed to keep
track of references files
This is "Restore on a different table", "export" is when you're copying the
.snapshot/name folder to another cluster...
If you think in term of HardLink you don't need to copy the hfiles but just
doing an HardLink... more code is needed to use Reference Files but you can
avoid the copy. (Note that HLog need to be replayed, so this is the only one
that need to be copied.
{quote}
I currently have a snapshot. I want to send a copy of the snapshot to a remote
cluster so that it can provide read/write access to the data.
Is/should this be supported?
* Do both HBase instances need to be up at the same time?
* This process would need to dereference the snapshot's references and copy
them. What is it called? exporting?
{quote}
Yes this is "Import/Export" that besically is a distcp of the .snapshot/name
folder
I Think that is enough having both hdfs up at the same time.
Yeah in this case you need to physically copy the hfiles.
> 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
