hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yi Liang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18105) [AMv2] Split/Merge need cleanup; currently they diverge and do not fully embrace AMv2 world
Date Wed, 14 Jun 2017 18:03:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049446#comment-16049446
] 

Yi Liang commented on HBASE-18105:
----------------------------------

Hi [~stack],
   I have a problem now, in the current split logic, if the split rowkey = null, the split
will find the best split points for that region, and split it. However this logic does not
exist in SplitProcedure.  I think we need to support this in splitProcedure. I have a idea
to solve this problem, which is add a property called bestSplitPoints in HRegionInfo, since
splitProcedure always send a rpc request to RSrpcservice to check the region is splitable
or not. We can get this bestSplitPoints from this rpc request as well, or do you have other
good idea?   

  in the current split logic, it is easy  to get the best split points, since they happen
at RSRpcServices.splitRegion(see path1 for split), which is in rs side, they can get region
server and region info easily. 

> [AMv2] Split/Merge need cleanup; currently they diverge and do not fully embrace AMv2
world
> -------------------------------------------------------------------------------------------
>
>                 Key: HBASE-18105
>                 URL: https://issues.apache.org/jira/browse/HBASE-18105
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Region Assignment
>    Affects Versions: 2.0.0
>            Reporter: stack
>             Fix For: 2.0.0
>
>
> Region Split and Merge work on the new AMv2 but they work differently. This issue is
about bringing them back together and fully embracing the AMv2 program.
> They both have issues mostly the fact that they carry around baggage no longer necessary
in the new world of assignment.
> Here are some of the items:
> Split and Merge metadata modifications are done by the Master now but we have vestige
of Split/Merge on RS still; e.g. when we SPLIT, we ask the Master which asks the RS, which
turns around, and asks the Master to run the operation. Fun. MERGE is all done Master-side.
>  
> Clean this up. Remove asking RS to run SPLIT and remove RegionMergeRequest, etc. on RS-side.
Also remove PONR. We don’t Points-Of-No-Return now we are up on Pv2. Remove all calls in
Interfaces; they are unused. Make RS still able to detect when split, but have it be a client
of Master like anyone else.
> Split is Async but does not return procId
> Split is async. Doesn’t return the procId though. Merge does. Fix. Only hard part here
I think is the Admin API does not allow procid return.
> Flags
> Currently OFFLINE is determined by looking either at the master instance of HTD (isOffline)
and/or at the RegionState#state. Ditto for SPLIT. For MERGE, we rely on RegionState#state.
Related is a note above on how split works -- there is a split flag in HTD when there should
not be.
>  
> TODO is move to rely on RegionState#state exclusively in Master.
> From Split/Merge Procedures need finishing in https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.4b60dc1h4m1f



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message