[
https://issues.apache.org/jira/browse/HBASE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905121#action_12905121
]
Jonathan Gray commented on HBASE-2240:
--------------------------------------
bq. Yes. It takes clients a while finding new locations. With our current
client at least, reopens that come close together can result in the client
failing with NSRE.
I don't see how this would be different whether region was open for a long time
at its location or not. If the region had been in one place for a while, most
clients will have a valid cache value, so moving it will invalidate every
client. This will give clients an NSRE. A region that had just recently moved
probably has clients that still are stale when it moves the second time. So
you'd potentially have less NSREs in total. Right?
bq. History would also help prevent the slightly pathological case where its
always the same region that gets moved on a rebalance.
That would be somewhat weird behavior, but this history approach is kind of at
odds with the cost-based approach.
bq. Currently balancer runs every minute. I should up the default.
+1
bq. Marking issue minor.
Cool with me. Just want to push for a more generalizable, cost-based approach
to balancing.
> 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
> Components: documentation
> Reporter: stack
> Priority: Minor
>
> 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.
