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-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time
Date Fri, 04 May 2012 04:07:05 GMT

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

stack commented on HBASE-5494:
------------------------------

bq. I think it makes sense to have a separate JIRA (or perhaps another patch for the same
JIRA?) to address this...

Yes. Would be a separate JIRA.  I'm just trying to have it so it is a continuation of the
work done here rather than a different table locking facility that runs beside this one because
we need read/writes and that there can be multiple read locks outstanding at anyone time;
one per region currently splitting/merging.

On region-level locks, we do not need this I'd say (Already, region changes go via zk and
there'll be failed transitions if concurrent operators try manipulate a single region given
we usually check znode sequence id before we go forward moving a region to a new state).

You thought this overkill for your case?   http://zookeeper.apache.org/doc/r3.1.2/recipes.html#Shared+Locks
 That is fine.  Do you think we could backfill it later underneath the patch attached here?

On the lock being left in place on master crash, whats wrong w/ that?  Thats sort of what
we want I'd say.  Or more, what we really want is that when the new master comes up, he finishes
off what the previous master was at.  To that end, should lock and unlock be public apis on
the master at all, but rather just internal primitives used by the master doing disable/enable?
 If you disable a table, the first think you do is obtain a lock and then when done, you let
it go on completion.   A new master that comes up after a previous master has crashed and
sees a table in disabling state should go ahead and complete the disable moving the table
state to disabled and when done, then it undoes the unlock to finish the schema change transaction;
you'd have to let the second master be able to undo the lock (Over in accumulo they have a
system where they allow describing a macro change in terms of distinct steps; the steps are
posted to zk and then acted on.  We don't have to be that smart just yet... we can hardcode
disable/enable for now).

Good stuff Alex.




                
> Introduce a zk hosted table-wide read/write lock so only one table operation at a time
> --------------------------------------------------------------------------------------
>
>                 Key: HBASE-5494
>                 URL: https://issues.apache.org/jira/browse/HBASE-5494
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: stack
>         Attachments: D2997.3.patch, D2997.4.patch
>
>
> I saw this facility over in the accumulo code base.
> Currently we just try to sort out the mess when splits come in during an online schema
edit; somehow we figure we can figure all possible region transition combinations and make
the right call.
> We could try and narrow the number of combinations by taking out a zk table lock when
doing table operations.
> For example, on split or merge, we could take a read-only lock meaning the table can't
be disabled while these are running.
> We could then take a write only lock if we want to ensure the table doesn't change while
disabling or enabling process is happening.
> Shouldn't be too hard to add.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message