[
https://issues.apache.org/jira/browse/PHOENIX-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanuj Khurana resolved PHOENIX-7974.
------------------------------------
Resolution: Fixed
> Forwarder must preserve origin server identity in the peer destination path
> to avoid same-timestamp file collisions wedging SYNC re-entry
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-7974
> URL: https://issues.apache.org/jira/browse/PHOENIX-7974
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Tanuj Khurana
> Assignee: Tanuj Khurana
> Priority: Major
>
> When the fallback cluster forwards replication log files to the peer standby
> cluster, ReplicationLogDiscoveryForwarder.processFile computed the peer
> destination path as:
> {code:java}
> getWriterPath(sourceTs, forwardingServerName){code}
> This keys the destination filename <ts>_<server>.plog on the forwarding
> RegionServer's own name, discarding the origin writer's identity. The origin
> RS's (server, timestamp) uniqueness invariant is therefore lost on the peer.
> When two source log files share the same timestamp but originate from
> different origin RegionServers, both collapse onto a single destination path.
> Because the copy uses FileUtil.copy(..., overwrite=false), the second file is
> permanently rejected with PathExistsException. processFile throws on every
> retry, so processOneRandomFile never calls markCompleted, the source stays in
> out_progress, and the HA group is held in SYNC_AND_FORWARD long after the
> data has actually been replicated — SYNC re-entry is wedged indefinitely.
> Root cause
> The destination filename must reproduce the origin RS's (server, timestamp)
> pair so it inherits that writer's existing uniqueness guarantee. Keying on
> the forwarding RS instead breaks the invariant precisely for
> cross-RegionServer same-timestamp files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
