hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7305) ZK based Read/Write locks for table operations
Date Tue, 19 Mar 2013 20:23:16 GMT

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

Jonathan Hsieh commented on HBASE-7305:

[~enis] Thanks for clarifying the scope of this, I think understanding-wise I'm on the same
page now.  

bq. The recent patch for HBASE-7403 moves the regions to be merged to the same region server.
We might be able to do in-memory locking for merge and split in the RS, so that we might be
able to use read locking for merges.

I like that.  This approach simplifies one problem.  I'm thinking it may push it towards another
(region assignment races), but I'll take a look over there.

bq. Yes, there is no protection against that right now. I have to look up why region move
causes snapshot to fail.

With the current snapshot implementation, in an ideal situation, when a table is being snapshotted
would lock the location of regions (no region moves) and the list of regions (no splits).
 If either happens, the expected list of regions snapshotted and then actual list of regions
snapshotted may differ and a verifcation step when taking a snapshot will fail alerting the
user.  We could change the snapshotting implementation to be immune from moves (region names
are the same), but it still would be susceptible to split/merge actions (since introduces
new regions).

I've got a chart kicking around in my head that tries to highlight which operations class
and where locks are or could be used to guard concurrent modifications. Hopefully I'll get
a draft up in the next few days, and post to dev@.
> ZK based Read/Write locks for table operations
> ----------------------------------------------
>                 Key: HBASE-7305
>                 URL: https://issues.apache.org/jira/browse/HBASE-7305
>             Project: HBase
>          Issue Type: Bug
>          Components: Client, master, Zookeeper
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 0.95.0
>         Attachments: 130228-zkrwlocks.pdf, 7305-v11.txt, hbase-7305_v0.patch, hbase-7305_v10.patch,
hbase-7305_v13.patch, hbase-7305_v14.patch, hbase-7305_v15.patch, hbase-7305_v1-based-on-curator.patch,
hbase-7305_v2.patch, hbase-7305_v4.patch, hbase-7305_v9.patch, HBaseTableLocks.pdf
> This has started as forward porting of HBASE-5494 and HBASE-5991 from the 89-fb branch
to trunk, but diverged enough to have it's own issue. 
> The idea is to implement a zk based read/write lock per table. Master initiated operations
should get the write lock, and region operations (region split, moving, balance?, etc) acquire
a shared read lock. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message