Page History

...

1. User sends StopMirrorTopics request with topics and mirror name.
2. The controller validates each topic belongs to the specified mirror and is in MIRRORING state. It then updates the topic config by appending the .removed suffix, e.g. mirror.name=my-mirror.removed, generating a ConfigRecord.
3. When the MirrorMetadataManager gets notified, it detects the .removed suffix on mirror.name. It queries the current mirror partition state from the coordinator, and transitions the mirror partition to STOPPING.
4. During STOPPING, the following operations execute sequentially:
   
   1. The MirrorFetcherManager removes all fetcher threads for the affected partitions, stopping replication.
   2. The LME is recorded as LastMirrorEpochsKey/LastMirrorEpochsValue records into the __mirror_state topic for potential future failback.
   3. The leader epoch is bumped for the partitions to ensure monotonically increasing epochs for new records.

   4. ABORT markers are appended for all ongoing transactions. For each partition, ProducerStateManager provides the set of in-flight transaction entries and an EndTransactionMarker(ABORT) is appended for each one. This resolves hanging transactions without truncating committed data.

      The LME is recorded as LastMirrorEpochsKey/LastMirrorEpochsValue records into the __mirror_state topic for potential future failback

      .

   5. A MIRROR_PID_RESET control record is written to the partition log, which expires all ProducerStateManager entries so that new producers get fresh PIDs with no collision risk.

5. The state transitions from STOPPING to STOPPED. The read only flag is cleared and the topic becomes writable. New producers can start producing with fresh PIDs starting at sequence 0 and a higher leader epoch.

...