[
https://issues.apache.org/jira/browse/HBASE-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-1506:
-------------------------
Attachment: split.patch
This patch implements two things:
1. If the regionserver has something report the master -- a close, a split,
etc. -- it does not wait to send it (Splits are 4 messages, opens are two
messages usually -- these are still sent in a batch but this patch means less
baching at the benefit of faster reaction to cluster event).
2. The lower half of a split is assigned immediately to the local regionserver.
Only the top half is given to the master to assign.
Splits should run a little faster. 1. above takes away a small piece of the
delay. 2. means that there is half the master/regionserver interaction getting
daughter regions back on line.
Will be back with a few numbers.
> [performance] Make splits faster
> --------------------------------
>
> Key: HBASE-1506
> URL: https://issues.apache.org/jira/browse/HBASE-1506
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: stack
> Priority: Critical
> Fix For: 0.20.1, 0.21.0
>
> Attachments: split.patch
>
>
> Regionservers run splits. They close the region to split, divide it, and
> then tell master about the two new regions. Master then assigns new regions.
> New regions need to come up in new locations. Both regions are offline
> during this time.
> Instead, regionserver might run split as it does now but new, deploy the
> lower-half on the current regionserver immediately. It'd then inform master
> that it had split, and that it was serving the lower half. Master would then
> take care of assigning the upper half.
> Benefits would be that clients who were accessing the lower half of the split
> would not need to go through recalibration. They'd just keep working.
> There'd be disruption for those keys that landed in the top half of the split
> only.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
