[
https://issues.apache.org/jira/browse/HBASE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905115#action_12905115
]
Jonathan Gray commented on HBASE-2240:
--------------------------------------
This seems invalid now, in my mind.
What is the reasoning behind wanting to have a history of rebalances? Is there
some reason we would never want to rebalance a region that was just recently
opened (for some definition of recent).
I'm pretty sure this jira was dealing with the region assignment churn because
we are determining to balance on each heartbeat, so it was literally balancing
a region to be on a server, then unassigning for another server almost
immediately. Now that it's in the background, waits for no regions to be in
transition, and will only ever do one move of a given region per load-balance,
this does not seem valid anymore.
A load-balance will run periodically (minutes). Is it the case that we would
not want to move a region from A to B in one balance. And then 30 minutes
later to move the same region from B to C (or wherever)? Not sure I follow why
this is very important to not move a region in successive balances (if our
algorithm, now or later, decides this is best to achieve "balance").
We should put smarts into that algorithm. A high cost could be associated with
moving a region if, for example, it had a large MemStore so it would require a
big flush. Or, even to implement what's being discussed here, a high cost
could be related to how long ago a region opened at its current location (but
again, I'm having a hard time knowing whether we'd bias old or new ones...
other stuff is probably better to make decisions based on)
> Balancer should not reassign (because of overloading) a region that was just
> opened
> -----------------------------------------------------------------------------------
>
> Key: HBASE-2240
> URL: https://issues.apache.org/jira/browse/HBASE-2240
> Project: HBase
> Issue Type: Bug
> Reporter: stack
>
> I'm running a mapreduce job. I see a region split and its daughters come on
> line and then 8 seconds later, master judges the regionserver overloaded and
> so closes the just-opened region. This messes up clients. They may have
> just picked up the new location for their row query and now its moved again
> and client has to go hunting anew.
> We need to assign the vintage regions first.
> I'm going to change balancer slop. Its not sloppy enough and balancing cuts
> in too early.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
