Duo Zhang commented on HBASE-20182:

We have a stop row now so it is impossible to get a record for another table. 
And now when region is a split parent then we will skip to the next row in meta 
so info.isSplit is not a stop sign.

And for the isOffline, I kept it in the ConnectionImplementation since it is 
there for a very long time, and it is no harm. For async client, since it is 
new, I would like to do an aggressive change.

Here is the comment for the offLine flag in HRegionInfo
  // This flag is in the parent of a split while the parent is still referenced
  // by daughter regions.  We USED to set this flag when we disabled a table
  // but now table state is kept up in zookeeper as of 0.90.0 HBase.
  private boolean offLine = false;

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 check.

What is thinking on below....


We might end up scanning more than 5 rows... that'd be ok?
I'm not sure whether we may scan more than 5 rows, but caching is not a hard 
limit so it is OK to scan more than 5 rows. In the test I added here we need to 
scan 2 rows.


> 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-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