Cluster Mirroring: Rethinking Cross-Cluster Replication from Inside the Broker

Cross-cluster replication is essential for disaster recovery, geographic distribution, and data migration. Today, MirrorMaker 2 is the standard tool for this job, but it comes with well-known trade-offs: a separate Connect cluster to deploy and monitor, lossy offset translation that causes duplicate processing during failover, etc.

KIP-1279 takes a different approach. Cluster Mirroring embeds cross-cluster replication directly into the Kafka broker runtime, eliminating external infrastructure entirely. But getting this right is harder than it looks. The design had to solve several subtle problems:

- Unclean leader elections on either cluster can silently diverge replica logs, yet failover and failback must remain consistent.

- Transactional records carry producer state that becomes stale the moment a mirror topic turns writable, yet idempotent producers must be able to resume cleanly.

- Leader epochs on source and destination can drift apart, yet consumers must be able to fetch from their last committed offset without falling into infinite metadata refresh loops.

- Source clusters can run versions as old as Kafka 2.1, long before leader epochs or modern fetch features existed, yet the mirroring protocol must still guarantee consistent replication and clean failover across this version gap.

In this session we walk through the architecture and design decisions behind Cluster Mirroring, showing how we solved each of these technical challenges and what trade-offs we made along the way.