---
title: "Confluent Cluster Linking: offset-preserving Kafka mirroring"
description: "Confluent Cluster Linking copies a Kafka topic byte for byte at the same offsets into a read-only mirror, syncs consumer offsets as-is, then promotes it."
url: https://monedula.dev/kafka-simulator/scenarios/cluster-linking-offset-preserving/
---

# Confluent Cluster Linking: offset-preserving Kafka mirroring

Scenario 10.2.1 · Cluster Linking: byte-for-byte offset-preserving mirror. 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 it: https://monedula.dev/kafka-simulator/playground/?scenario=10.2.1

## 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](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.1&t=0)
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](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.1&t=1)
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](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.1&t=2)
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](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.1&t=3)

## 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.

## Further reading

- [Confluent documentation](https://docs.confluent.io/platform/current/multi-dc-deployments/cluster-linking/index.html)