[
https://issues.apache.org/jira/browse/HBASE-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160177#comment-13160177
]
Ben West commented on HBASE-3373:
---------------------------------
We're running 0.94 and ran into this. With 4 region servers, we had one table
with ~1800 regions, evenly balanced. We then used importtsv to import ~300
regions of a new table. We ended up with virtually all regions on one server;
when I look at the master's log it looks like there were 159 rebalances (which
makes sense); 123 were moving regions from the old table, and 26 moved new
table regions. The result is that about 90% of the regions of the new table are
on one server.
When I look at DefaultLoadBalancer.balanceCluster, it has:
{CODE}
// fetch in alternate order if there is new region server
if (emptyRegionServerPresent) {
fetchFromTail = !fetchFromTail;
}
{CODE}
so we're only doing the randomization stuff in HBASE-3609 if there's a new
region server? Is there a reason we don't do this all the time?
> Allow regions of specific table to be load-balanced
> ---------------------------------------------------
>
> Key: HBASE-3373
> URL: https://issues.apache.org/jira/browse/HBASE-3373
> Project: HBase
> Issue Type: Improvement
> Components: master
> Affects Versions: 0.20.6
> Reporter: Ted Yu
> Attachments: HbaseBalancerTest2.java
>
>
> From our experience, cluster can be well balanced and yet, one table's
> regions may be badly concentrated on few region servers.
> For example, one table has 839 regions (380 regions at time of table
> creation) out of which 202 are on one server.
> It would be desirable for load balancer to distribute regions for specified
> tables evenly across the cluster. Each of such tables has number of regions
> many times the cluster size.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
