hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy Xiang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9052) Prevent split/merged region from assigning again
Date Mon, 29 Jul 2013 22:05:49 GMT

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

Jimmy Xiang commented on HBASE-9052:

bq. nit: regionOffline should be renamed setRegionOffline or offlineRegion?
Sure, I will change regionOffline/regionOnline to offlineRegion/onlineRegion

bq. I see tightening up of allowed states but how are we prevening assign of MERGE and SPLIT?
That's prevented by the AM#assign method already. For regular assignment, it requires the
region to be in offline/closed state.  For forcing assignment, it requires the region to be
in a closing(or pending close), opening(or pending open).  Now, since we move the region to
SPLIT/MERGE state, they won't be assigned any more unless the state is changed to offline/closed.

If master fails over, we lose these states. However, the merged regions are not known the
new master any more since they are deleted from meta. So they won't be assigned either.  For
split region, the isSplit/isOffline flag is used in rebuilding user regions so they won't
be picked up either.

> Prevent split/merged region from assigning again
> ------------------------------------------------
>                 Key: HBASE-9052
>                 URL: https://issues.apache.org/jira/browse/HBASE-9052
>             Project: HBase
>          Issue Type: Bug
>          Components: Region Assignment
>    Affects Versions: 0.95.1
>            Reporter: Jimmy Xiang
>            Assignee: Jimmy Xiang
>         Attachments: trunk-9052.patch
> If a region is split/merged, before it's removed from meta, you can still assign it from
the HBase shell. It's better to prevent this from happening.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message