Skip to content

HBASE-30334 Reopen parent regions on rollback of MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS - #8583

Open
nirdosh0110 wants to merge 2 commits into
apache:masterfrom
nirdosh0110:HBASE-30334
Open

HBASE-30334 Reopen parent regions on rollback of MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS#8583
nirdosh0110 wants to merge 2 commits into
apache:masterfrom
nirdosh0110:HBASE-30334

Conversation

@nirdosh0110

@nirdosh0110 nirdosh0110 commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Summary

  • The MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS case in MergeTableRegionsProcedure.rollbackState() was a bare break;. When rollback fires at this step (e.g. checkClosedRegions fails), the parent regions stay CLOSED and produce an indefinite stuck RIT with no automatic recovery.
  • Fall through CHECK_CLOSED_REGIONS to CLOSE_REGIONS so the existing rollbackCloseRegionsForMerge helper reopens the parents via AssignmentManagerUtil.reopenRegionsForRollback.
  • Mirrors the analogous SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS handling in SplitTableRegionProcedure.rollbackState() (which calls openParentRegion(env)).

JIRA: https://issues.apache.org/jira/browse/HBASE-30334

Test plan

  • Existing rollback tests in TestMergeTableRegionsProcedure still pass.
  • Manual/soak: force checkClosedRegions to throw in a merge procedure and confirm parents get reopened on rollback (no stuck RIT).

cleanupMergedRegion(env);
break;
case MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS:
break;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we need this change? In general, when rolling back a procedure, finally we will arrive the MERGE_TABLE_REGIONS_CLOSE_REGIONS state and reopen the parent regions?

nirdosh.yadav added 2 commits September 1, 2026 12:41
…CHECK_CLOSED_REGIONS

MergeTableRegionsProcedure.rollbackState() previously had a bare `break;`
for the MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS case. When rollback
fires at this state (e.g. checkClosedRegions() throws on a stale
recovered.edits file), the parents were expected to be reopened on the
next rollback tick through MERGE_TABLE_REGIONS_CLOSE_REGIONS. In
production this cascade did not fire reliably: an OpenTSDB tsdb merge
observed on cluster hbase31a on 2026-08-05 stayed RIT for 48 minutes
until operator intervention, with no TRSP submitted for either parent
during rollback.

Mirror the pattern SplitTableRegionProcedure.rollbackState() already
uses for the symmetric SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS state:
call the reopen helper (rollbackCloseRegionsForMerge) directly on the
failing state's own rollback body, and make the follow-on
MERGE_TABLE_REGIONS_CLOSE_REGIONS an explicit no-op with the mirror
comment from SplitTableRegionProcedure so duplicate
TransitRegionStateProcedures are not submitted for parents already
OPENING. The invariant is that any pre-PONR state that can fail owns
its own rollback reopen, rather than relying on the framework cascading
to the next state.
…_REGIONS failure

Plants a stale recovered.edits file on a parent so that
MERGE_TABLE_REGIONS_CHECK_CLOSED_REGIONS throws (the exact trigger
observed on the hbase31a stuck-RIT incident on 2026-08-05), submits a
merge, and asserts both parents transition back to OPEN after rollback.
Verifies the rollback body reopens the parents on the failing state's
own tick, mirroring the pattern SplitTableRegionProcedure already
exercises for SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants