hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dhruba borthakur (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-1730) Near-instantaneous online schema and table state updates
Date Fri, 22 Jul 2011 07:02:57 GMT

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

dhruba borthakur commented on HBASE-1730:
-----------------------------------------

> I like Ryans' dictum that we store transitory info in zk only, not permanent info like
table schemas.

Completely agree. All schema info resides in .tableinfo and it will continue to reside there.


My current proposal for this jira is to make the alter-table command go to the master to update
the .tableinfo file. Then the master will trigger the normal close/open sequence for each
region-id to all relevant regionservers. There will be some throttling built in so that all
regions of the table do not encounter a close/open sequence at the same time. 

The master will not maintain persistant state on which region-ids has been closed/opened;
if the master dies before all regionids were closed/opened, then an admin has to issue a disable/enable
command to propage the schema change to all region servers.

Does this sound reasonable?

 

> Near-instantaneous online schema and table state updates
> --------------------------------------------------------
>
>                 Key: HBASE-1730
>                 URL: https://issues.apache.org/jira/browse/HBASE-1730
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Purtell
>            Assignee: stack
>            Priority: Critical
>             Fix For: 0.92.0
>
>         Attachments: 1730-v2.patch, 1730-v3.patch, 1730.patch
>
>
> We should not need to take a table offline to update HCD or HTD. 
> One option for that is putting HTDs and HCDs up into ZK, with mirror on disk catalog
tables to be used only for cold init scenarios, as discussed on IRC. In this scheme, regionservers
hosting regions of a table would watch permanent nodes in ZK associated with that table for
schema updates and take appropriate actions out of the watcher. In effect, schema updates
become another item in the ToDo list.
> {{/hbase/tables/<table-name>/schema}}
> Must be associated with a write locking scheme also handled with ZK primitives to avoid
situations where one concurrent update clobbers another. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message