hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15156) Support first assignment of split daughters to non-parent RS
Date Tue, 02 Feb 2016 17:32:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128623#comment-15128623

stack commented on HBASE-15156:

bq. stack quick question - mind telling me why branch-1 and not both master and branch-1?

nvm. AM is changing in master is what I meant. Hopefully the need for this sort of interpolation
at multiple points changing an AM process that no one really understands adding new failure
modes that will be found six months down the line when we've all forgotten what was done here
will happen less. Master does AM in AMv2. A config that says assign to servers other than
that of the parents will be an easier insert.

> 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

View raw message