stack commented on HBASE-20182:

I meant this finding of yours on review of the code => "And I checked the code, 
now the flag will only be set to split parent. In DisableTableProcedure, 
finally we will create bunch of UnassignProcedures and at the last of the 
procedure we will set the region state to CLOSED, and will not change the 
offLine flag. So I think the check here is redundant with the isSplitParent 

It looks like we can strip the second sentence from the comment on 'private 
boolean offLine = false;'.

Later we should remove these 'state' flags from regions altogether.... 
including the 'spliit' one. 'offline' is a table attribute kept in the table 
enabled/disabled flag... and whether region is CLOSED or OPEN. TODO is undo the 
split flag similarly.


> Can not locate region after split and merge
> -------------------------------------------
>                 Key: HBASE-20182
>                 URL: https://issues.apache.org/jira/browse/HBASE-20182
>             Project: HBase
>          Issue Type: Bug
>          Components: Region Assignment
>            Reporter: Duo Zhang
>            Assignee: Duo Zhang
>            Priority: Blocker
>             Fix For: 2.0.0
>         Attachments: HBASE-20182-UT.patch, HBASE-20182-addendum.patch, 
> HBASE-20182-v1.patch, HBASE-20182-v2.patch, HBASE-20182-v3.patch, 
> HBASE-20182-v3.patch, HBASE-20182-v3.patch, HBASE-20182.patch
> When implementing serial replication feature in HBASE-20046, I found that 
> when splitting a region, we will not remove the parent region, instead we 
> will mark it offline.
> And when locating a region, we will only scan one row so if we locate to the 
> offlined region then we are dead.
> This will not happen for splitting, since one of the new daughter regions 
> have the same start row with the parent region, and the timestamp is greater 
> so when doing reverse scan we will always hit the daughter first.
> But if we also consider merge then bad things happen. Consider we have two 
> regions A and B, we split B to C and D, and then merge A and C to E, then 
> ideally the regions should be E and D, but actually the regions in meta will 
> be E, B and D, and they all have different start rows. If you use a row 
> within the range of old region C, then we will always locate to B and throw 
> exception.

This message was sent by Atlassian JIRA

Reply via email to