[
https://issues.apache.org/jira/browse/HBASE-10576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981427#comment-13981427
]
Jeffrey Zhong commented on HBASE-10576:
---------------------------------------
[~rajesh23]
{quote}
(Need not have any special state like shadow)
{quote}
You can't reuse disabled state because a client can't talk to a region in a
disabled table. Introducing a new state like "shadow", I think it's cleaner.
{quote}
I will do prototype of this
{quote}
Please do.
[[email protected]] Just changing balancer alone isn't enough. Because even
we send out region assignment requests simultaneously with same destination RS,
there is no guarantee which assignment will happen firstly, when they will
happen & complete and if they can both succeed.
With this coprocessor approach, since both region open the same time, we can
even atomically update both their location info in meta table with a single
batch. So clients can see both of them in a location at the same time.
[~giacomotaylor] The new proposal is to enforce strong co-locating. We still
need same split key & prefix for the index regions. There are other ways
without requiring same split key/prefix but they're not clean. Since there is
an entry in meta table for the index region with "shadow" state, a client can
scan the region directly.
Thanks.
> Custom load balancer to co-locate the regions of two tables which are having
> same split keys
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-10576
> URL: https://issues.apache.org/jira/browse/HBASE-10576
> Project: HBase
> Issue Type: Sub-task
> Components: Balancer
> Reporter: rajeshbabu
> Assignee: rajeshbabu
> Attachments: HBASE-10536_v2.patch, HBASE-10576.patch
>
>
> To support local indexing both user table and index table should have same
> split keys. This issue to provide custom balancer to colocate the regions of
> two tables which are having same split keys.
> This helps in Phoenix as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)