Page History

...

• UNKNOWN: The partition has no cached state (broker just became leader, state not loaded yet). Not an explicit API-driven state, just the absence of state.
• PREPARING: The coordinator for this partition detects via onMetadataUpdate that it leads a mirror partition. It fetches last mirrored epochs from the source cluster and truncates logs to align the local log with the source.
• MIRRORING: All ISR set members have completed truncation. A mirror fetcher thread is started to continuously replicate records from the source cluster.
• PAUSING: Triggered by the pause operation. The system removes fetchers for the affected partitions. Valid from: MIRRORING only.
• PAUSED: Fetchers have been removed. The partition stays read-only with no active fetchers and no metadata sync (configs, consumer groups, ACLs). On resume, transitions directly to MIRRORING.
• STOPPING: Performs the following actions.
  1. Remove mirror fetcher threads: Stops cross-cluster replication for the affected partitions.
  2. In parallel:
     1. Bump leader epoch (async): Sends a BumpLeaderEpochsRequest to the controller with the latest local log epoch as minLeaderEpoch, ensuring the destination leader epoch exceeds the source cluster's last known epoch.

     2. Truncate to LSO, then update LME: Truncates each partition's log to LSO, discarding any uncommitted tail, then persists the latest leader epoch from each partition's log into the __mirror_state coordinator topic, recording LME for future failback.

  3. Write PID reset barrier: Once both parallel branches complete, appends a MIRROR_PID_RESET control record to each partition, fencing stale producer IDs from the source cluster.
• STOPPED: The topic becomes writable on the destination cluster. The mirror fetcher is removed and the read-only flag is cleared.
• FAILED: An error occurred. Valid from: any state. The operator that wants to restart a failed mirror partition can remove the topic from the mirror and add it back again. The STOPPING handler already removes fetchers and truncates to the LSO, both of which are safe operations on a failed partition (fetchers are likely already gone, and truncation is a best-effort cleanup). More sophisticated recovery strategies can be added later with a follow-up KIP.

...