[
https://issues.apache.org/jira/browse/HBASE-29782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050231#comment-18050231
]
Charles Connell commented on HBASE-29782:
-----------------------------------------
Merged to master. Working on some git auth issues before I cherry-pick to
branch-3. Waiting for branch-2 PR.
> Expose public Admin API to reopen table regions without moving
> --------------------------------------------------------------
>
> Key: HBASE-29782
> URL: https://issues.apache.org/jira/browse/HBASE-29782
> Project: HBase
> Issue Type: Improvement
> Components: Admin, master, proc-v2
> Reporter: Alex Hughes
> Assignee: Alex Hughes
> Priority: Minor
> Labels: pull-request-available
>
> Currently, when modifying a table descriptor with
> {{{}reopenRegions=false{}}}, there is no straightforward way to reopen
> regions without moving them to different servers. The only workaround is to
> call {{move()}} on each region individually, which is expensive as it
> triggers cross-server data transfers.
> This limitation makes it difficult to gradually roll out table descriptor
> changes for large, latency-sensitive production tables. Operators need the
> ability to:
> # Reopen regions in-place (without server-to-server moves)
> # Target specific regions for canary testing before full rollout
> # Leverage existing batching/throttling (HBASE-28215) for controlled
> deployments
> The {{ReopenTableRegionsProcedure}} already supports in-place region
> reopening via {{{}TransitRegionStateProcedure.reopen(){}}}, but this
> functionality is not exposed through the public {{Admin}} API.
> h3. Motivation
> For production environments, modifying table descriptors can be disruptive:
> * Setting {{reopenRegions=true}} causes simultaneous reopening of all
> regions, creating a "RIT storm" that impacts availability
> * Setting {{reopenRegions=false}} leaves regions unaware of changes, with no
> clean way to roll them out gradually
> * Using {{move()}} operations is unnecessarily expensive, involving network
> I/O and cross-server coordination when regions could simply reopen in-place
> A public API for gradual, in-place region reopening enables safer, more
> controlled rollouts of table configuration changes, particularly for large
> tables serving latency-sensitive workloads.
> h3. Proposed Solution:
>
> {code:java}
> // Reopen all regions for a table (in-place, no move)
> void reopenTableRegions(TableName tableName)
> Future<Void> reopenTableRegionsAsync(TableName tableName)
> // Reopen specific regions (for canary testing)
> void reopenTableRegions(TableName tableName, List<RegionInfo> regions)
> Future<Void> reopenTableRegionsAsync(TableName tableName, List<RegionInfo>
> regions) {code}
> These methods will:
> * Invoke the existing {{ReopenTableRegionsProcedure}} with appropriate
> region targeting
> * Support batching/throttling via existing configurations
> ({{{}hbase.reopen.table.regions.progressive.batch.*{}}})
> * Validate that specified regions belong to the target table
> * Perform in-place reopens using {{TransitRegionStateProcedure.reopen()}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
