You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jonathan Hsieh (JIRA)" <ji...@apache.org> on 2013/02/05 17:25:55 UTC
[jira] [Comment Edited] (HBASE-7365) Safer table creation and
deletion using .tmp dir
[ https://issues.apache.org/jira/browse/HBASE-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571426#comment-13571426 ]
Jonathan Hsieh edited comment on HBASE-7365 at 2/5/13 4:24 PM:
---------------------------------------------------------------
Looked at the code, Master-side DeleteTableHandler does the following steps:
# wait for related RITs to resolve
# delete entries from META
# mv table to /hbase/.tmp
# archive regions in /hbase/.tmp
# delete .tmp delete table dir
# update master table desc cache
# rm AM's zk entry (is this always present?).
HBaseAdmin waits for:
# table meta entries to be deleted
# HMaster.getTableDescriptors file to be deleted
Matteo says the problem seems to be that the HMaster.getTableDescriptors looks at the hdfs and file is "deleted" when move hdfs table data to .tmp. (Thi sseems to say the table returns as deleted before the .tmp stuff and ZK stuff is cleaned up.
Look like we could:
# use the same steps but check the .tmp dir for the tableinfo descriptor? We could add a getDeletingTableDescriptors method (that checks the .tmp delete dir) so the HBaseAdmin can poll and waits until it is gone, or trigger on when the .tmp delete table dir is gone.
# use the AM's setDeletedTable/getDeletedTable znode as the last set? (need to look into this more)
# Move table to temp before deleting from meta?
was (Author: jmhsieh):
Looked at the code, Master-side DeleteTableHandler does the following steps:
# wait for related RITs to resolve
# delete entries from META
# mv table to /hbase/.tmp
# archive regions in /hbase/.tmp
# delete .tmp table dir
# update master table desc cache
# rm AM's zk entry (is this always present).
HBaseAdmin waits for:
# table meta entries to be deleted
# HMaster.getTableDescriptors file to be deleted
Matteo says the problem seems to be that the HMaster.getTableDescriptors looks at the hdfs and file is "deleted" when move hdfs table data to .tmp. (Thi sseems to say the table returns as deleted before the .tmp stuff and ZK stuff is cleaned up.
Look like we could:
# use the same steps but check the .tmp dir for the tableinfo descriptor? We could add a getDeletingTableDescriptors method (that checks the .tmp delete dir) so the HBaseAdmin can poll and waits until it is gone, or trigger on when the .tmp delete table dir is gone.
# use the AM's setDeletedTable/getDeletedTable znode as the last set? (need to look into this more)
# Move table to temp before deleting from meta?
> Safer table creation and deletion using .tmp dir
> ------------------------------------------------
>
> Key: HBASE-7365
> URL: https://issues.apache.org/jira/browse/HBASE-7365
> Project: HBase
> Issue Type: Improvement
> Components: master
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Fix For: 0.96.0
>
> Attachments: 7365-v4.patch, HBASE-7365-v0.patch, HBASE-7365-v1.patch, HBASE-7365-v2.patch, HBASE-7365-v3.patch
>
>
> Currently tables are created in the root directory, and the removal works on the root directory.
> Change the code to use a /hbase/.tmp directory to make the creation and removal a bit safer
> Table Creation steps
> * Create the table descriptor (table folder, in /hbase/.tmp/)
> * Create the table regions (always in temp)
> * Move the table from temp to the root folder
> * Add the regions to meta
> * Trigger assignment
> * Set enable flag in ZooKeeper
> Table Deletion steps
> * Wait for regions in transition
> * Remove regions from meta (use bulk delete)
> * Move the table in /hbase/.tmp
> * Remove the table from the descriptor cache
> * Remove table from zookeeper
> * Archive the table
> The main changes in the current code are:
> * Writing to /hbase/.tmp and then rename
> * using bulk delete in DeletionTableHandler
--
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