tanyastickles commented on PR #8700: URL: https://github.com/apache/hbase/pull/8700#issuecomment-5875867392
> I think we have the same problem for mergeRegions method? We should also record the MERGED state for the merge parent regions I suppose. for MERGED, we should be safe. when merging, we write a tombstone to the regionInfo ([code](https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/RegionStateStore.java#L425)), so if the hmaster rolls and we need to construct the state from meta, the region gets ignored. we also set the state to `CLOSED` to explicitly avoid this issue. ``` // Set initial state to CLOSED. // NOTE: If initial state is not set to CLOSED then merged region gets added with the // default OFFLINE state. If Master gets restarted after this step, start up sequence of // master tries to assign this offline region. This is followed by re-assignments of the // merged region from resumed {@link MergeTableRegionsProcedure} MetaTableAccessor.addRegionStateToPut(putOfMerged, RegionInfo.DEFAULT_REPLICA_ID, RegionState.State.CLOSED); ``` in the split case, the meta state was CLOSED but because the regionInfo had the `offline=true` flag set, it still got assigned as an offline region. that won't happen in the MERGED case. we could persist the state as MERGED to the meta for consistency in "terminal states are saved to the meta" but as far as i can tell, it shouldn't change the existing logic. i don't have strong opinions either way, so defer to your preference here! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
