A producer ID (PID) is a 64-bit identifier assigned by the broker to each idempotent or transactional producer. It has three key properties:
Without PID mapping, two independent clusters can assign the same producer ID to different producers. When records from both source clusters are mirrored into the same destination partition, the ProducerStateManager (PSM) sees two unrelated producers sharing one PID.
The following PID transformation is applied before appending mirrored data to the destination cluster:
-(PID + 2) |
This is a simple negation that maps all non-negative PIDs into the negative space. The +2 offset avoids mapping PID 0 to 0 and keeps PID -1 (non-idempotent) untouched.
There are a couple of problems with this approach that are evident when looking at the chained mirroring use case.
When B mirrors to C, PIDs already negative from A get re-transformed: -((-7) + 2) = 5 , which restores the original PID and collides with local producers on C.
A B C D
-1 -------> -1 -------> -1 -------> -1
5 -------> -7 --------> 5 -------> -7
5 -------> -7 # collision |
Even if we make the mapping idempotent by skipping negative PIDs, when A has local PID 5 and B also has local PID 5, both map to -7 on any downstream cluster. These are different producers, but they become indistinguishable. The PSM cache stores the transformed PID with no awareness of its origin, so a collision silently overwrites the previous entry breaking txn consistency within the log.
A B C 5 -------> -7 -------> -7 5 -------> -7 # collision |
We identified the following issues caused by interleaving records from a PID collision:
Rather than transforming PIDs at write time, this approach proactively expires stale producer state on failover. The key insight is that during mirroring, the destination partition is read-only: no local producers exist, so all PSM entries originate from mirrored data. When mirroring stops, all PSM entries are stale and can be safely expired. Records from the source are stored as-is on the destination, with no PID modification, which otherwise would require a checksum recalculation. A MIRROR_PID_RESET control batch (type 7) is written to each destination partition's log during the STOPPING state transition, after the fetcher has been removed and truncation to last stable offset is complete, but before the partition becomes writable.
A B C
5(A) -------> 5(A) -------> 5(A) # 5(A) means PID:5, source cluster:A
CB -------> CB # Control Batch appended when A failover to B
5(B) -------> 5(B) # In B and C, even if 2 records with PID 5, they won't duplicate with each other because of the control batch. |
The mirror partition state transitions are:
The key follows the standard control record format (version=0, type=7). The value uses the MirrorPidResetRecord schema:
{
"type": "data",
"name": "MirrorPidResetRecord",
"validVersions": "0",
"flexibleVersions": "0+",
"fields": [
{ "name": "Version", "type": "int16", "versions": "0",
"about": "The version of the mirror PID reset record."},
{ "name": "SourceClusterId", "type": "string", "versions": "0",
"about": "The source cluster UUID for verification."}
]
} |
The SourceClusterId field records which source cluster the mirrored data came from, enabling future validation (e.g. detecting unexpected source cluster changes) and data provenance tracing from the log itself.
When the barrier batch is encountered during append or during log recovery, all producer entries are removed from the PSM. This ensures leaders, followers, and recovery all handle the barrier consistently. Because the partition is read-only during mirroring, all PSM entries originate from mirrored data. Expiring all entries is safe: no local producer state exists to preserve. Control batches are filtered out by the consumer fetcher via isControlBatch checks. The barrier is invisible to application consumers, just like transaction markers (commit/abort). The log dump tool is enhanced to deserialize and display MIRROR_PID_RESET records.
The barrier approach works correctly with all practical mirroring topologies:
Failback (A to B, then B to A): After failover, B becomes writable. Later, A starts mirroring from B and truncates its log to the LSO. A then stores B's records as-is. B's barrier record is included in the fetched data and appended to A's log, triggering PSM expiration on A. This is consistent with the general rule: when the barrier batch is encountered during append or during log recovery, all producer entries are removed from the PSM. A will write its own barrier when it eventually stops mirroring from B, producing a clean slate before A becomes writable again.