[
https://issues.apache.org/jira/browse/HBASE-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781572#comment-13781572
]
James Kinley commented on HBASE-8710:
-------------------------------------
needsBalance() uses an instance of ClusterLoadState to determine how many
servers are active in the cluster. By default,
"hbase.master.loadbalance.bytable" is false and therefore ClusterLoadState has
a global view of the cluster and how many servers there are. If
"hbase.master.loadbalance.bytable" was set to true then ClusterLoadState will
only have a per table view of the cluster. In this case, if the logic was moved
to needsBalance() then the balancer may or may not run for each table, it will
definitely not run when the cluster has a single server, but needsBalance()
will be called for each table. Is this what you would expect?
Is there any reason why ClusterLoadState and ClusterStatus cannot be merged? At
the moment, a new instance of both is created every time the balancer is run
and ClusterStatus is only used by StochasticLoadBalancer. Wouldn't it be better
to have a single ClusterStatus object that also contains load information, and
to call balancer.needsBalance() from HMaster#balance() before
balancer.balanceCluster()?
The two other checks in HMaster#balance() could also be moved into
balancer.needsBalance() - isRegionsInTransition() and
areDeadServersInProgress().
> The balancer shouldn't try balancing one node
> ---------------------------------------------
>
> Key: HBASE-8710
> URL: https://issues.apache.org/jira/browse/HBASE-8710
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.95.1
> Reporter: Jean-Daniel Cryans
> Assignee: James Kinley
> Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-8710-1.patch, HBASE-8710-2.patch
>
>
> In my logs, testing 0.95.1 RC1, I see:
> {noformat}
> 2013-06-07 17:31:47,377 DEBUG
> [ip-10-20-46-44.novalocal,48569,1370640098134-BalancerChore]
> balancer.StochasticLoadBalancer: Could not find a better load balance plan.
> Tried 3200 different configurations in 27ms, and did not find anything with a
> computed cost less than 25.0
> {noformat}
> Ideally we'd not even try one configuration, let alone 3.2k.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
