[
https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605886#comment-13605886
]
Enis Soztutar commented on HBASE-7305:
--------------------------------------
Thanks Jon, I was in the process of updating the doc, but got carried away with
more pressing issues. I'll attach an updated version.
Your overview seems about right.
bq. This primarily protects operations that clash with table level
enable/disable/alter, but not region level operations, right?.
If you mean assign, etc. Not it does not.
bq. This doesn't guard meta from individual changes, right? It only protects
meta from bulk adds (create/delete table). Thus this shouldn't affect region
moves or region closes/opens.
There is no guard against changes to META. Region moves, open/close does not
acquire a lock.
bq. If an overlapping merge and split were issued, some other mechanism is in
place to keep this sane right? This doesn't protect multiple merge requests
with overlapping regions right?
bq. Merges will likely want the read lock? (allowing multiple concurrent
merges, and assuming some overlap sanity protection from a different mechanism).
Merges can be designed to acquire read lock or a write lock. If read lock, then
it means there is no guarantee against trying to do a merge and a concurrent
split. But this allows merges for different ranges happening at the same time.
If we do write lock, it will guard against concurrent merge / split problem,
but we cannot do multiple merges at the same time.
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.
bq. With snapshots, this mechanism doesn't prevent regions from moving so it
only protects snapshots from concurrently happening with enable/disable/alter
table ops. Snapshot will still fail if it gets caught while the balancer is
running.
Yes, there is no protection against that right now. I have to look up why
region move causes snapshot to fail.
bq. These locks don't really help hbck – except for the cases where
enable/disable/alter operations are going on as hbck repairs things. (It
wouldn't "protect" hbck from the balancer").
hbck as it is relies too much on knowing about the filesystem layout, and META.
It is hard to sync between balancer and hbck.
bq. Does having a table lock (and then having individual region locks that
require a table read lock being held) make sense? Maybe this makes sense for
merges and splits?
If we have per-region locks, we might reevaluate table locks. But I would
imagine so, since it will prevent concurrent master operations as well. We can
achieve the same thing with acquiring all the region locks, but table locks
would be faster.
bq. having individual region locks that require a table read lock being held
I think we have to evaluate whether this is feasible. I guess it should be, but
we should be able to scale to millions of regions. If we had per-region locks,
assignment would become much easier (current RIT is similar, but we need this
even for assigned regions)
> 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
