Monedula

Scenario 10.2.1 · Cluster Linking: byte-for-byte offset-preserving mirror

Confluent Cluster Linking: offset-preserving Kafka mirroring

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

A cluster link mirrors a topic to another cluster keeping the SAME offsets (no translation) into a read-only mirror you can promote - vs MM2, which re-produces and translates offsets.

Run this scenario in the playground

Promote the mirror - read-only orders becomes writable. t+1.900s

promote_mirror flipped primary.orders from a read-only mirror to a normal writable topic (mirrorState 'promoted') and stopped mirroring it. The simulator drops cl-orders, which carried only this topic; a real cluster link stays up for any other mirror topics. The MM2 payments link is untouched - MM2 has no promote lifecycle.

Open at this step: step 4, Promote the mirror - read-only orders becomes writable

What you start with

Confluent Cluster Linking mirrors a topic to another cluster while preserving the exact same offsets - no translation table - into a read-only mirror you can later promote. This contrasts with MirrorMaker 2, which re-produces each record and must maintain a source→target offset map.

Step by step

  1. Two links to dr - a cluster link on orders, MM2 on payments t+0.000s primary serves orders + payments. cl-orders is a CLUSTER LINK (offset-preserving): its destination primary.orders is a READ-ONLY mirror, named here as if the link set cluster.link.prefix, since Confluent otherwise keeps the source name orders. mm-payments is MirrorMaker 2 (the default): it re-produces payments into primary.payments and translates offsets. Open at this step: step 1, Two links to dr - a cluster link on orders, MM2 on payments
  2. Offsets preserved (cluster link) vs translated (MM2) t+0.700s Both destinations now hold 3 records. The cluster link copied orders byte-for-byte: primary.orders offsets == source offsets, and the link carries NO offsetMap. MM2 re-produced payments and built an offsetMap translation table on mm-payments - same numbers here, but it is the machinery cluster linking avoids. Open at this step: step 2, Offsets preserved (cluster link) vs translated (MM2)
  3. Consumer offsets synced 1:1 across the cluster link t+1.100s g1 read + committed orders on primary. At the t=1000 sync tick the cluster link copied g1's committed offset AS-IS onto cl-orders (no translation) - so a consumer cutting over to the promoted mirror resumes at the exact same offset. Open at this step: step 3, Consumer offsets synced 1:1 across the cluster link
  4. Promote the mirror - read-only orders becomes writable t+1.900s promote_mirror flipped primary.orders from a read-only mirror to a normal writable topic (mirrorState 'promoted') and stopped mirroring it. The simulator drops cl-orders, which carried only this topic; a real cluster link stays up for any other mirror topics. The MM2 payments link is untouched - MM2 has no promote lifecycle. Open at this step: step 4, Promote the mirror - read-only orders becomes writable

The takeaway

Because Cluster Linking copies records byte-for-byte at identical offsets, a consumer can fail over to the mirror and resume at the same positions with no offset remapping.

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.1" title="Kafka Simulator: Cluster Linking: byte-for-byte offset-preserving mirror" 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-offset-preserving/">Confluent Cluster Linking: offset-preserving Kafka mirroring</a></p>

Further reading

Confluent documentation

More in Disaster recovery

All scenarios