HBASE-30323 [RSGroup] Forward-port HBASE-22658 to branch-2 - #8547
Open
Umeshkumar9414 wants to merge 1 commit into
Open
HBASE-30323 [RSGroup] Forward-port HBASE-22658 to branch-2#8547Umeshkumar9414 wants to merge 1 commit into
Umeshkumar9414 wants to merge 1 commit into
Conversation
RegionMover.unloadRegions() previously picked destination servers from all online RegionServers regardless of RSGroup membership, potentially trying to move regions out of their assigned group during server decommission, althoug HMaster prevents it. This is a branch-2-compatible port of HBASE-22740. On master/branch-3 the fix used admin.getRSGroup() which is integrated directly into the Admin interface (via HBASE-22971). On branch-2 RSGroup remains an optional coprocessor (RSGroupAdminEndpoint), so we: 1. Check for RSGroupAdminEndpoint via getMasterCoprocessorNames() to skip the RSGroup path on clusters that do not use RSGroups. 2. Call getRSGroupInfoOfServer() via the RSGroupAdminService coprocessor RPC, using the unshaded protobuf service from hbase-protocol. 3. Filter the destination server list to only servers in the same RSGroup (filterRSGroupServers); filtering is always applied by membership — the DEFAULT_GROUP short-circuit that could leak regions across groups is removed. 4. Log a DEBUG message when hasRSGroupInfo()==false to aid diagnosis of hostname-vs-IP address-form mismatches (HBASE-27304). RSGroupAdmin.proto is moved from hbase-rsgroup to hbase-protocol so that hbase-server can use RSGroupAdminService without creating a circular dependency with hbase-rsgroup. Both modules depended on the same generated FQN; consolidating in hbase-protocol (which both already depend on) is best I could think of. Tests: - TestRegionMoverWithRSGroupEnable (hbase-rsgroup): 5-node mini cluster integration test with RSGroupAdminEndpoint enabled. Verifies that unloading a non-default-group server places all regions exclusively on the remaining server in that group (positive assertion) and that no default-group server receives any of those regions (isolation assertion). Also tests the guard path: unloading a default-group server succeeds end-to-end when RSGroups are enabled. - TestRegionMoverFilterRSGroupServers (hbase-server): unit tests for filterRSGroupServers() — default group returns full server list, non-default group filters to members only, no-match group returns empty. Co-authored-by: Claude Sonnet 4.6 <claude@anthropic.com>
mnpoonia
approved these changes
Aug 12, 2026
virajjasani
approved these changes
Aug 12, 2026
Contributor
There was a problem hiding this comment.
How about adding an IT test case for scenario when all servers in test RS group go down and fallback config is enabled (hbase.rsgroup.fallback.enable = true), then regions from test RS group do move to default RS group servers on calling RegionMover.unload().
| .map(JVMClusterUtil.RegionServerThread::getRegionServer) | ||
| .filter(rs -> rs.getServerName().equals(defaultSN)).findFirst().get(); | ||
| assertEquals(0, decommRS.getRegions(defaultTable).size(), | ||
| "Decommissioned default-group server must hold no regions after unload"); |
Contributor
There was a problem hiding this comment.
Can we also please add assertion that default group regions don't land on test RS group servers?
|
|
||
| /** A non-default group with one member must return only that member. */ | ||
| @Test | ||
| public void testNonDefaultGroupFiltersToMembers() throws Exception { |
Contributor
There was a problem hiding this comment.
Can we add a test case where there is default RS group and some test RS group. And, assertion is that output of filter for default RS group should not have any server of test RS group. Please correct me if my understanding is wrong.
Contributor
Author
There is already test written for that, 'TestRSGroupsFallback'. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RegionMover.unloadRegions() previously picked destination servers from all online RegionServers regardless of RSGroup membership, potentially trying to move regions out of their assigned group during server decommission, althoug HMaster prevents it.
This is a branch-2-compatible port of HBASE-22740. On master/branch-3 the fix used admin.getRSGroup() which is integrated directly into the Admin interface (via HBASE-22971). On branch-2 RSGroup remains an optional coprocessor (RSGroupAdminEndpoint), so we:
RSGroupAdmin.proto is moved from hbase-rsgroup to hbase-protocol so that hbase-server can use RSGroupAdminService without creating a circular dependency with hbase-rsgroup. Both modules depended on the same generated FQN; consolidating in hbase-protocol (which both already depend on) is best I could think of.
Tests: