---
title: "Kafka consumer offset sync: Cluster Linking vs MirrorMaker 2"
description: "Both groups commit offset 3. Confluent Cluster Linking syncs it as-is, Kafka MirrorMaker 2 translates it, and both reprocess commits made after the last sync."
url: https://monedula.dev/kafka-simulator/scenarios/consumer-offset-sync-link/
---

# Kafka consumer offset sync: Cluster Linking vs MirrorMaker 2

Scenario 10.2.4 · Consumer offset sync across a link. Disaster recovery · Advanced · about 4 min · Apache Kafka 4.3.

A cluster link syncs committed consumer offsets AS-IS (committed === translated) because offsets are preserved; MM2 instead translates them through its offsetMap. Both sync on a cadence, so commits after the last sync are reprocessed either way.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=10.2.4

## What you start with

Cluster Linking can sync committed consumer-group offsets across the link. Because the mirror preserves source offsets exactly, a synced offset arrives as-is (committed === translated) and a consumer resumes at the same record; MirrorMaker 2 instead translates offsets through its offsetMap at the checkpoint cadence.

## Step by step

1. **Two links, two consumers** (t+0.000s): g1 reads + commits on orders (mirrored by a CLUSTER LINK); g2 reads + commits on payments (mirrored by MM2). Both links checkpoint consumer offsets at the same cadence (mirrorCheckpointMs), so the only difference will be how each translates the committed offset. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.4&t=0)
2. **Both groups committed** (t+0.800s): Each group has drained its three records and committed offset 3 ({0:3}). The mirrors are caught up too, so the destination high-watermarks match the source. Nothing is synced across the links yet - that waits for the checkpoint tick. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.4&t=1)
3. **Offsets synced over the links** (t+1.100s): The checkpoint at t=1000 syncs both groups. CLUSTER LINK cl-orders: committed === translated (3 === 3) - offsets are preserved, so the synced offset IS the committed offset, with no translation. MM2 mm-payments: the committed offset is run through the offsetMap translation. On both links a failover replays whatever was committed after the last sync, so the reprocess window is set by the sync cadence (see 09.2.4). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.4&t=2)

## The takeaway

Offset-preserving sync means a failed-over consumer resumes exactly at its last synced offset with no translation, whereas MM2's translated checkpoints can land early; on both, anything committed after the last sync is reprocessed.

## Further reading

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