[
https://issues.apache.org/jira/browse/HBASE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090010#comment-13090010
]
stack commented on HBASE-1730:
------------------------------
@Ted Would suggest you just point out error in the Nicolas comment rather than
edit the comments of someone else. Its hard to grok why an edit (though in
above you say why).
@Subbu On 1., your soln. looks like it would be more 'scalable'. On 2., 1730,
we learned yesterday, has been deployed in a production context and purportedly
works (This true Nicolas?). On 3., IIRC, Karthik's reasoning was that with
1730 you can tell if it failed or not since master is keeping running tab on
state (If failure -- master dies or failed close/open of region -- then manual
intervention to disable/enable table was fine he reasoned). With 4213, the
thought was that it was not as easy seeing whether operation succeeded or not.
Another point bantered about was that 1730 has region granularity whereas 4213
goes by regionserver; it was thought that it'd be easier to figure the problem
region in 1730 case.
> 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
