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)