hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-1730) Near-instantaneous online schema and table state updates
Date Tue, 23 Mar 2010 16:21:27 GMT

     [ 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.

View raw message