[
https://issues.apache.org/jira/browse/HBASE-15156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15129839#comment-15129839
]
stack commented on HBASE-15156:
-------------------------------
bq. What was the reason it was faster?
No trip to the master to have it do assigment rpc'ing other servers; all was
done local on the splitting regionserver.
bq. I don't think there's much difference in zkless land since everything has
to go through the master now before becoming visible.
True
bq. What would need to be done to get it into trunk?
We can commit to trunk. It will be refactored later as part of the AM redo that
is ongoing (Matteo and Stephen).
bq. ; .. the parent?
Comment then please.
bq. Because it's just a waste of RPC. We already do something similar if the RS
performing the split dies, so this is not unprecendent.
HBase is like the Bible; you can find a precedent for any argument you might
like to make in it (smile). onRegionSplit is where I'd expect to find the
assign. Its ok.
> Support first assignment of split daughters to non-parent RS
> ------------------------------------------------------------
>
> Key: HBASE-15156
> URL: https://issues.apache.org/jira/browse/HBASE-15156
> Project: HBase
> Issue Type: New Feature
> Reporter: Francis Liu
> Assignee: Francis Liu
> Attachments: HBASE-15156.patch
>
>
> On region split, the region's daughter is always opened by the same region
> server hosting the parent region. In some cases this is not ideal:
> This feature was mainly needed for favored nodes to allow for more freedom
> when selecting favored nodes for daughter regions. ie The daughter doesn't
> have to always select the regionserver hosting the split as a favored node
> which should allow for better favored node distribution.
> Though this feature is actually useful in cases where region splits occur
> much more often than the balancer is run. It also is a bit more efficient as
> the major compaction that occurs after daughter assignment does not go to
> waste (ie cancelled half-way, loss of locality due to move, etc). We actually
> run it this way in some of our clusters even without favored nodes enabled.
> Hence I am supplying a patch which is independent of favored nodes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
