lokiore opened a new pull request, #2638: URL: https://github.com/apache/phoenix/pull/2638
JIRA: https://issues.apache.org/jira/browse/PHOENIX-8025 ### What changes were proposed in this pull request? `IndexRegionObserver#getReplicationLogGroup` now checks for the PARALLEL HA policy before it resolves the `ReplicationLogGroup`. A CLIENT_HA write for a PARALLEL group gets no replication writer on any cluster role: it commits locally and is never shipped through the consistent-failover replication log. Before this change, the policy was checked only after `ReplicationLogGroup.get()` returned empty, which happens only on a non-active cluster. - PARALLEL, active cluster: commits locally with no replication-log append (previously shipped to the peer). - PARALLEL, non-active cluster: commits locally (unchanged). - FAILOVER, active cluster: resolves the writer and ships (unchanged). - FAILOVER, non-active cluster: rejected by the split-brain guard (unchanged). Because a PARALLEL batch resolves no writer, its WAL key carries no HA group, so the WAL-restore path (`getHAGroupFromWALKey`) never re-ships it either. `isParallelPolicy` now treats an unreadable HA group record (an `IOException` from the store) the same way it already treated a missing one: as not PARALLEL. The method moved ahead of writer resolution, so this keeps the existing behavior when the store can't be read. A FAILOVER group on the active cluster still gets its cached writer, and a write with no writer still fails through the existing paths. ### Why are the changes needed? A PARALLEL HA group doesn't need consistent-failover log replication. The PARALLEL client writes every mutation to both clusters, and PARALLEL tables use HBase native replication to keep the clusters converged. Shipping the active cluster's PARALLEL writes through the replication log as well: - adds a synchronous write to the peer's replication log before each PARALLEL write on the active cluster can return; - makes the standby apply each write three times: the client's direct write, HBase native replication, and the replication-log replay; - exposes PARALLEL groups to the replication log's failure modes. For example, a failure writing to the peer's file system can fail-stop the region server, even though PARALLEL never relies on the log. ### Does this PR introduce _any_ user-facing change? Not in any released version. The change is limited to the unreleased PHOENIX-7562 feature branch. On that branch, PARALLEL writes on the active cluster are no longer written to the consistent-failover replication log or replayed on the peer. They reach the peer through the client's own write and HBase native replication. FAILOVER behavior doesn't change. ### How was this patch tested? - New unit test `IndexRegionObserverReplicationLogGroupTest` (9 tests) for `getReplicationLogGroup`: - PARALLEL on the active or non-active cluster returns no writer. - FAILOVER on the active cluster returns the writer. - FAILOVER on a non-active cluster throws. - A missing HA group record keeps the existing resolution. - An unreadable store still returns the cached FAILOVER writer, and still fails when there is no writer. - Non-CLIENT_HA origins and non-replicated tables return no writer without looking up the store. - New IT case `ReplicationLogGroupParallelIT#testParallelWriteOnActiveClusterIsNotShippedToReplicationLog`: a PARALLEL client writes rows that land on both clusters, and the active cluster's replication log has no records for that table. The existing PARALLEL non-active case still passes. - Negative control: with the PARALLEL check temporarily moved back below the writer lookup (the old ordering), `testParallelOnActiveReturnsNoWriter` fails. The new IT case also fails because it finds the PARALLEL table's write in the replication log (`{T_N000001=1}`). Both pass with the fix. ``` mvn verify -pl phoenix-core -am -Dtest=IndexRegionObserverReplicationLogGroupTest \ -Dit.test=ReplicationLogGroupParallelIT -Dsurefire.failIfNoSpecifiedTests=false \ -Dfailsafe.failIfNoSpecifiedTests=false ``` ### Was this patch authored or co-authored using generative AI tooling? Yes. Authored with Claude Code (Opus 4.8); reviewed and tested by the author. Generated-by: Claude Code (Opus 4.8) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
