PHOENIX-7994 Add cross-cluster IT for server-side immutable-index regeneration on the standby - #2608
Draft
lokiore wants to merge 1 commit into
Draft
Conversation
…eneration on the standby Consistent Failover replicates only data-table mutations; secondary-index tables carry no capture coprocessor, so an index is never shipped as index-table entries. For an IMMUTABLE table the standby regenerates the index from the replayed data mutations via IndexRegionObserver, and that only happens when index maintenance is deferred to the server via phoenix.server.side.immutable.indexes.enabled. Adds ReplicationLogGroupImmutableIndexIT (extends ReplicationLogGroupBaseIT): creates an IMMUTABLE table + global index with the config enabled on the client connection, asserts the replication log carries data-table mutations only, replays the log on cluster 2, and asserts the standby index is fully regenerated (count served by the index, index in the explain plan, cell-equal across clusters). The cross-cluster index equality is the config gate: with the flag disabled the standby index is empty and the assertion fails. Fills the immutable gap next to the mutable sibling ReplicationLogGroupIT#testIndexRegenerationOnStandby. Generated-by: Claude Code (Opus 4.8) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
What changes were proposed in this pull request?
Adds
ReplicationLogGroupImmutableIndexIT(@Category(NeedsOwnMiniClusterTest.class), extendingReplicationLogGroupBaseIT) — a cross-cluster integration test for server-side immutable-index maintenance (phoenix.server.side.immutable.indexes.enabled) under Consistent Failover replication.The single test
testImmutableIndexRegeneratedOnStandby:IMMUTABLE_ROWS=truetable + global index on cluster 1 with the config enabled on the client connection, and upserts 10 rows.ReplicationLogProcessor.COUNT(*)served by the index returns all rows, the index appears in the explain plan, and both the data table and the index are cell-equal across clusters.Test-only change; no product code is touched.
Why are the changes needed?
Consistent Failover replicates only data-table mutations — secondary-index tables carry no capture coprocessor, so an index is never shipped as index-table entries. For an IMMUTABLE table the standby therefore has to regenerate the index from the replayed data mutations via
IndexRegionObserver, and that only happens when index maintenance is deferred to the server viaphoenix.server.side.immutable.indexes.enabled. With that config disabled, an immutable table's index is maintained client-side; those index writes land only on the active's index table (never replicated) and the data batch is not marked for server-side regeneration — so after replay the standby index is left empty and diverges from the data table.Existing immutable-index coverage (
ServerSideImmutableIndexIT) is single-cluster only. There was no cross-cluster test proving the standby index is regenerated when the config is enabled. The cross-cluster index equality in this test is the config gate — with the flag disabled on the client the standby index is empty and the assertion fails. The sibling mutable-table case already exists asReplicationLogGroupIT#testIndexRegenerationOnStandby; this fills the immutable gap.Does this PR introduce any user-facing change?
No. Test-only.
How was this patch tested?
New integration test
ReplicationLogGroupImmutableIndexIT.mvn -pl phoenix-core test-compilepasses andmvn spotless:checkis clean. The test spins up two mini-clusters (NeedsOwnMiniClusterTest) and is intended to run under the failsafe integration-test phase in CI.Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8)