[ 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