hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3112) Enable and disable of table needs a bit of loving in new master
Date Sat, 06 Nov 2010 04:32:41 GMT

    [ https://issues.apache.org/jira/browse/HBASE-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928929#action_12928929
] 

stack commented on HBASE-3112:
------------------------------

On way home was thinking of how I need a disabling/enabling state for a table.  I need at
least for case where a split is happening when a region is being disabled.  When splits go
to open on the regionserver, they should check zk if table is disabled or disabling and pass
on the open (splits don't do state up in zk).

@Jon Disable and enable are run from executor.  In each case, we do a get of all regions in
a table and then per region we run unassign inline inside in the executor.  Any failure of
a server while this process is going on makes for a table that is partially disabled/enabled.



> Enable and disable of table needs a bit of loving in new master
> ---------------------------------------------------------------
>
>                 Key: HBASE-3112
>                 URL: https://issues.apache.org/jira/browse/HBASE-3112
>             Project: HBase
>          Issue Type: Bug
>            Reporter: stack
>            Assignee: stack
>            Priority: Critical
>             Fix For: 0.90.0
>
>
> The tools are in place to do a more reliable enable/disable of tables.  Some work has
been done to hack in a basic enable/disable but its not enough -- see the test avro/thrift
tests where a disable/enable/disable switchback can confuse the table state (and has been
disabled until this issue addressed).
> This issue is about finishing off enable/disable in the new master.   I think we need
to add to the table znode an enabling/disabling state rather than have them binary with a
watcher that will stop an enable (or disable) starting until the previous completes (Currently
we atomically switch the state though the region close/open lags -- some work in enable/disable
handlers helps in that they won't complete till all regions have transitioned.. but its not
enough).
> Need to add tests too.
> Marking issue critical bug because loads of the questions we get on lists are about enable/disable
probs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message