[
https://issues.apache.org/jira/browse/HBASE-15156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126900#comment-15126900
]
stack commented on HBASE-15156:
-------------------------------
We assign daughters to the same node as parent because this way we can get the
data back on line more promptly.
On patch, seems fine for branch-1. Should update doc on method to say sna and
snb are optional on splitRegion.
This is odd:
public static final String ASSIGN_DAUGHTERS_AFTER_SPLIT =
"hbase.split.unassign";
Varname talks about ASSIGN but config String says unassign.
Why not swap order on this if/else rather than negate the if condition... makes
it harder to read:
if (!shouldAssignAfterSplit) {
Could you group the two clausees that get invoked when shouldAssignAfterSplit
== true ?
What region is being offlined here: regionOffline(hri, State.SPLIT); .. the
parent?
Why not have this assign happen in the call to onRegionSplit?
We do this check in two places....
!services.getConfiguration().getBoolean(HConstants.ASSIGN_DAUGHTERS_AFTER_SPLIT,
false)) {
Seems like should be one place where we do it.
The patch changes APIs to add optional new daughter assign servers and then
does checks in a bunch of places taking different forks dependent on whether
daughters are to be assigned elsewhere or not. Its not pretty. Could this
feature be better contained? For instance, could the assign happen inside in
the onRegionSplit? Could the assign be done inside in the
SplitRegionTransaction rather than up in AM so it aligned better with how our
current split works?
If not, patch will work, for branch-1 at least.
> 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)
