Scenario 10.2.3 · Cluster Linking vs MirrorMaker 2: when to use which

Cluster Linking vs MirrorMaker 2 for Kafka replication

Disaster recovery · Advanced · about 4 min · Apache Kafka 4.3

Same topology, two replication models side by side: a cluster link mirrors offset-preserving into a read-only mirror (no translation table); MM2 re-produces and maintains a source→target offsetMap.

What you start with

This scenario runs the two cross-cluster replication models side by side on the same topology. Cluster Linking mirrors offset-preserving into a read-only mirror with no translation table, while MirrorMaker 2 re-produces records through Connect and maintains a source→target offset map.

Step by step

1. Two links, two models t+0.000s Same topology, two replication models: orders is mirrored by a CLUSTER LINK (kind 'cluster-link') into a read-only mirror primary.orders (mirrorState 'mirror'); payments is mirrored by MIRRORMAKER 2 (the default) into primary.payments (just mirrored, no promote lifecycle). Open at this step: step 1, Two links, two models
2. Both mirroring in progress t+0.500s The cluster link copies orders OFFSET-PRESERVING (destination offset == source offset, no translation table). MM2 RE-PRODUCES payments and starts building a source→target offsetMap. Both destinations trail the source by the mirror cadence. Open at this step: step 2, Both mirroring in progress
3. Contrast: offsetMap vs none t+0.900s Steady state. CLUSTER LINK cl-orders: offsetMap UNDEFINED (offsets preserved), destination primary.orders read-only (mirrorState 'mirror'). MM2 mm-payments: offsetMap {0:{0:0,1:1,2:2}}, the simulator's per-record table (real MM2 keeps sparse offset syncs, so its translation can land a little early), and no mirrorState. Pick Cluster Linking for broker-native offset-preserving DR/migration inside Confluent; pick MM2 to bridge clusters that don't speak the linking protocol. Open at this step: step 3, Contrast: offsetMap vs none

The takeaway

Reach for Cluster Linking when you want identical offsets and a simple managed mirror (DR, migration); reach for MirrorMaker 2 when you need Connect-based flexibility and accept offset translation.

Embed this scenario

Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.

<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=10.2.3" title="Kafka Simulator: Cluster Linking vs MirrorMaker 2: when to use which" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/cluster-linking-vs-mm2/">Cluster Linking vs MirrorMaker 2 for Kafka replication</a></p>

Further reading

Confluent documentation

More in Disaster recovery

• Kafka stretched cluster across two data centers
• 2.5-DC Kafka stretched cluster with a witness site
• 3-DC Kafka cluster: the KRaft quorum survives losing a site
• Kafka in two DCs without a witness: KRaft quorum is lost
• Kafka data center failure: leader failover to the other DC
• Kafka network split inside one DC: ISR drops to the floor
• Kafka MirrorMaker 2 active-passive DR and replication lag
• Kafka DR failover with MirrorMaker 2: measuring RPO
• Active-active Kafka with MirrorMaker 2 and region topics
• MirrorMaker 2 offset translation for Kafka consumer failover
• Kafka failback after a MirrorMaker 2 DR failover
• Active-active Kafka DR drill: move clients to the survivor
• Confluent MRC observers: Kafka replicas outside the ISR
• Kafka observer lag in Confluent Multi-Region Clusters
• Kafka observer promotion in Confluent Multi-Region Clusters
• Confluent MRC observer promotion: losing the Kafka leader DC
• Kafka replica placement: durability vs latency across DCs
• Confluent Cluster Linking: offset-preserving Kafka mirroring
• Kafka mirror topics (Confluent): read-only until promoted
• Kafka consumer offset sync: Cluster Linking vs MirrorMaker 2
• Kafka failover and failback with Confluent Cluster Linking

All scenarios