You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Xiaolin Ha (JIRA)" <ji...@apache.org> on 2019/07/08 03:50:00 UTC

[jira] [Commented] (HBASE-22642) Move operations of RSGroup should allow retry and correct region assignments

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

Xiaolin Ha commented on HBASE-22642:
------------------------------------

Two important things of RSGroup are stored meta info and region movements. 

I think we can make move operations in RSGroup be idempotent, because repeatedly moving tables/servers to a group might not make regions be moved repeatedly, like the operations of balancing. Meta info contains reflects of group name and tables/servers, which should not mind to be written repeatedly.

As a result, there is no benefit of refusing to move tables/servers to a target group which is the same as their origin group.

Any comments is welcome. 

> Move operations of RSGroup should allow retry and correct region assignments
> ----------------------------------------------------------------------------
>
>                 Key: HBASE-22642
>                 URL: https://issues.apache.org/jira/browse/HBASE-22642
>             Project: HBase
>          Issue Type: Bug
>          Components: rsgroup
>            Reporter: Xiaolin Ha
>            Assignee: Xiaolin Ha
>            Priority: Major
>
> Currently, when moving tables or servers to a group, only groupInfo is checked. And in RSGroup implementation, groupinfo is written to disk before regions movements are done. If there are some problems caused move regions abort, some regions will be on wrong regionservers. What's the worse, retry the move operation will be rejected because of the correct groupinfo.
> We think when moving, not only groupInfo should be checked, but also relevant region assignments should be checked and corrected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)