[jira] [Created] (PHOENIX-7994) Add cross-cluster IT for server-side immutable-index regeneration on the standby

["Lokesh Khurana (Jira)" <ji...@apache.org>]

Lokesh Khurana created PHOENIX-7994:
---------------------------------------

             Summary: Add cross-cluster IT for server-side immutable-index regeneration on the standby
                 Key: PHOENIX-7994
                 URL: https://issues.apache.org/jira/browse/PHOENIX-7994
             Project: Phoenix
          Issue Type: Sub-task
            Reporter: Lokesh Khurana
            Assignee: Lokesh Khurana


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 via phoenix.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.
h2. Gap

Existing immutable-index coverage (ServerSideImmutableIndexIT) is single-cluster only. There is no cross-cluster test proving the standby index is regenerated when the config is enabled – nor a negative that shows it is empty when disabled.
h2. Proposed

Add ReplicationLogGroupImmutableIndexIT (@Category(NeedsOwnMiniClusterTest.class), extending the
replication-log-group base IT):
 - Create an IMMUTABLE table + global index on cluster 1 with the config enabled on the client connection, upsert N rows.
 - Assert the replication log carries data-table mutations only (no index-table entries) – structural confirmation.
 - Recreate the schema on cluster 2, replay the log via ReplicationLogProcessor.
 - Assert the standby index is fully regenerated: COUNT(*) served by the index returns N, the explain plan uses the index, and the index is cell-equal across clusters.
 - The cross-cluster index equality is the config gate – with the flag disabled on the client the standby index is empty and the assertion fails.

h2. Notes
 - The flag is a client-side decision (read in MutationState from the connection config), so it is set on the client properties, not on the server conf.
 - The mutable-table sibling case already exists (ReplicationLogGroupIT#testIndexRegenerationOnStandby);
this fills the immutable gap.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)