[
https://issues.apache.org/jira/browse/HBASE-20182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396518#comment-16396518
]
stack commented on HBASE-20182:
-------------------------------
bq. Why we need to retain the parent region when splitting?
We kept the parent around until both daughters were done with it.
On split, the daughters do not copy the data. They instead hold references to
files up in the parent region. As time progressed, eventually a daughter would
no longer need the parent files. It would mark this condition by deleting a
column in parent region. When both daughter columns were deleted, then we knew
it was safe to clean up the parent region both its entry in meta and its data
in fs.
Thats the way it has worked up to this. At time of implementation we didn't
have stuff like cross-row atomic operations or AMv2. We could do better now I'd
say (smile).
bq. And when locating a region, we will only scan one row so if we locate to
the offlined region then we are dead.
Which circumstance would return an offlined row?
bq. we split B to C and D...
Well, you'd split B to B and ... C, not C and D; i.e. first split would
parent's start row.. .then you would merge A and the new B... (You can only
merge contiguous regions)... I think your example not possible (perhaps I am
not following..).
On the test, there are two regions only after you split? Where does it fail?
Thanks.
> 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
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20182-UT.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
(v7.6.3#76005)
