[
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
