[
https://issues.apache.org/jira/browse/HBASE-29782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050395#comment-18050395
]
Hudson commented on HBASE-29782:
--------------------------------
Results for branch branch-3
[build #508 on
builds.a.o|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508/]:
(x) *{color:red}-1 overall{color}*
----
details (if available):
(x) {color:red}-1 general checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508//console].
(x) {color:red}-1 jdk17 hadoop3 checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop 3.3.5 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop 3.3.6 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(x) {color:red}-1 jdk17 hadoop 3.4.0 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 jdk17 hadoop 3.4.1 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase%20Nightly/job/branch-3/508/JDK17_20Nightly_20Build_20Report_20_28Hadoop3_29/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test for 3.3.5 {color}
(/) {color:green}+1 client integration test for 3.3.6 {color}
(/) {color:green}+1 client integration test for 3.4.0 {color}
(/) {color:green}+1 client integration test for 3.4.1 {color}
(/) {color:green}+1 client integration test for 3.4.2 {color}
> 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
> Fix For: 4.0.0-alpha-1, 3.0.0-beta-2
>
>
> 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)
