[
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
