[
https://issues.apache.org/jira/browse/HBASE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089862#comment-13089862
]
Subbu M Iyer commented on HBASE-1730:
-------------------------------------
Hi Nicolas,
Couple of call outs:
1. 4213, just like 1730, also implements the online schema change as
well. (but the pattern is slightly different, in that 4213 relies on
the RS cloud to refresh the online regions applicable for the table
with latest schema changes rather than master explicitly unassigning
and reassigning all the regions of the table). When we alter a table
with add/modify/delete CF the only thing that changes is the HTD for
the table, and since the RS has access to this new version of HTD
(after master completes the schema change) it can simply close/open a
region for the changes to take effect. This was the fundamental
assumption behind 4213's implementation.
2. The testing and maturity for 4213 is TBD/Unknown, as I don't have
the required resources (a real cluster setup) to perform the necessary
acid tests to comment on that.
3. Karthik & other developers had a handful of design concerns about 4123:
Could you please iterate those concerns so we can address them when we
add the persistent capability to 1730?
thanks
Subbu
On Tue, Aug 23, 2011 at 3:35 PM, Nicolas Spiegelberg (JIRA)
> 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,
> HBASE-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
