You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Francis Liu (JIRA)" <ji...@apache.org> on 2016/02/04 02:17:39 UTC

[jira] [Updated] (HBASE-15156) Support first assignment of split daughters to non-parent RS

     [ https://issues.apache.org/jira/browse/HBASE-15156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis Liu updated HBASE-15156:
--------------------------------
    Attachment: HBASE-15156_1.patch

Draft patch streamlining the split code to no longer use SPLIT transition. This is a draft since I haven't totally streamlined the changes (ie we no longer need the new splitRegion() related apis). Also had to update some tests...it seems some of them were buggy to begin with (ie some expect zk style assignment but we no longer have that option in trunk). I addressed some of the comments but not all since they'll go away if we go with this approach.

> 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, HBASE-15156_1.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)