[
https://issues.apache.org/jira/browse/HBASE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-1730:
-------------------------
Attachment: 1730-v3.patch
Here is latest state though a million miles from the finish. Doesn't all
compile yet.
+ HCD becomes ColumnFamliyDefinition object.
+ HTD becomes TableDefinition
+ New TableState objection (offline, readonly, etc.)
+ HBaseAdmin now becomes nothing but moving stuff around in ZK, no need of a
connection to cluster/master (Ryan noted that this means can do schema mods
though hbase is not running). All that evening stuff run by the master goes
away.
+ There are a bunch of additions to ZKWatcher but I think J-D has done the same
ones to make replication work. I need to pick up his pattern of moving all of
the master rewrite zk interactions to a class of their own rather than try and
squeeze all into ZKWatcher.
+ Tests that play around with zk. New TableData object is made of a
TableDefinition and a TableState. This is what we write out to a table znode.
> Near-instantaneous online schema and table state updates
> --------------------------------------------------------
>
> Key: HBASE-1730
> URL: https://issues.apache.org/jira/browse/HBASE-1730
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Assignee: stack
> Fix For: 0.21.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.
-
You can reply to this email to add a comment to the issue online.
