hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Yates (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6353) Snapshots shell
Date Tue, 10 Jul 2012 18:42:34 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410689#comment-13410689
] 

Jesse Yates commented on HBASE-6353:
------------------------------------

general comments:
* 'take snapshot' should have an type field (maybe -t option since timestamp is the default).

* we should probably slow down on this until the restore operations are in the java code first.
Makes the shell super easy and generally how people roll in stuff (also helps keep stuff logically
separate).

bq. What do you think about having mount and restore as separate feature? 

I feel like it should track the outline from HBASE-6230 in terms of naming. See my latest
comments (https://issues.apache.org/jira/browse/HBASE-6230?focusedCommentId=13410682&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13410682)
for thoughts on how the operations could also be named and a little bit of thought on how
they could work. 

                
> Snapshots shell
> ---------------
>
>                 Key: HBASE-6353
>                 URL: https://issues.apache.org/jira/browse/HBASE-6353
>             Project: HBase
>          Issue Type: New Feature
>          Components: shell
>            Reporter: Matteo Bertozzi
>            Assignee: Matteo Bertozzi
>         Attachments: HBASE-6353-v0.patch
>
>
> h6. hbase shell with snapshot commands
> * snapshot <snapshot name> <table name>
> ** Take a snapshot of the specified name with the specified name 
> * restore_snapshot <snapshot name>
> ** Restore specified snapshot on the original table
> * mount_snapshot <snapshot name> <table name> [readonly]
> ** Load the snapshot data as specified table (optional readonly flag)
> * list_snapshots [filter]
> ** Show a list of snapshots
> * delete_snapshot <snapshot name>
> ** Remove a specified snapshot
> h6. Restore Table
> Given a "snapshot name" restore override the original table with the snapshot content.
> Before restoring a new snapshot of the table is taken, just to avoid bad situations.
> (If the table is not disabled we can keep serving reads)
> This allows a full and quick rollback to a previous snapshot.
> h6. Mount Table (Aka Clone Table)
> Given a "snapshot name" a new table is created with the content of the specified snapshot.
> This operation allows:
>  * To have an old version of the table in parallel with the current one.
>  ** Look at snapshot side-by-side with the "current" before making the decision whether
to roll back or not
>  * To Restore only "individual items" (only some small range of data was lost from "current")
>  ** MR job that scan the cloned table and update the data in the original one. (Partial
restore of the data)
>  * if the table is not marked as read-only
>  ** To Add/Remove data from this table without affecting the original one or the snapshot.
> h6. Open points
>  * Add snapshot type option on take snapshot command (global, timestamp)?
>  * Keep separate the "restore" from "mount"?

--
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

        

Mime
View raw message