Scenario 12.0.3 · Capstone: migrate a cluster with Cluster Linking, zero downtime
Zero-downtime Kafka migration with Confluent Cluster Linking
An offset-preserving cluster link mirrors a live topic into a new cluster keeping identical offsets, syncs the consumer’s committed offset 1:1, then promote_mirror cuts over - the consumer resumes at the same offset on the new cluster with no reprocessing.
Run this scenario in the playgroundOld cluster live - cluster link to new. t+0.000s
The `old` cluster serves orders; the `new` cluster is the migration target. A Cluster Link (offset-preserving) is armed from old → new. The consumer g1 reads + commits on the old cluster.
Open at this step: step 1, Old cluster live - cluster link to newMirrored at identical offsets. t+0.700s
O1..O3 are produced on old and g1 drains them. The cluster link copies them byte-for-byte into new at the SAME offsets - old.orders on the new cluster is a read-only mirror whose offsets match the source exactly (no translation table).
Open at this step: step 2, Mirrored at identical offsetsCommitted offset synced 1:1. t+1.100s
The offset-sync checkpoint copies g1's committed offset onto the link as-is (identity) - because dest offset == source offset, there is nothing to translate. The new cluster now knows exactly where the consumer is.
Open at this step: step 3, Committed offset synced 1:1Cutover - promote_mirror, no reprocessing. t+1.900s
promote_mirror flips old.orders from a read-only mirror to a writable topic and detaches the link. Migration is complete: the consumer can resume on the new cluster at the identical committed offset, so it reprocesses nothing and skips nothing - zero-downtime cutover.
Open at this step: step 4, Cutover - promote_mirror, no reprocessingWhat you start with
A zero-downtime cluster migration with Confluent Cluster Linking. An offset-preserving link mirrors a live `orders` topic into a new cluster byte-for-byte at identical offsets (carrying no offset-translation table), and the link’s checkpoint syncs the consumer’s committed offset 1:1. Then promote_mirror flips the read-only mirror to a writable topic and cuts the consumer over.
Step by step
- Old cluster live - cluster link to new t+0.000s The `old` cluster serves orders; the `new` cluster is the migration target. A Cluster Link (offset-preserving) is armed from old → new. The consumer g1 reads + commits on the old cluster. Open at this step: step 1, Old cluster live - cluster link to new
- Mirrored at identical offsets t+0.700s O1..O3 are produced on old and g1 drains them. The cluster link copies them byte-for-byte into new at the SAME offsets - old.orders on the new cluster is a read-only mirror whose offsets match the source exactly (no translation table). Open at this step: step 2, Mirrored at identical offsets
- Committed offset synced 1:1 t+1.100s The offset-sync checkpoint copies g1's committed offset onto the link as-is (identity) - because dest offset == source offset, there is nothing to translate. The new cluster now knows exactly where the consumer is. Open at this step: step 3, Committed offset synced 1:1
- Cutover - promote_mirror, no reprocessing t+1.900s promote_mirror flips old.orders from a read-only mirror to a writable topic and detaches the link. Migration is complete: the consumer can resume on the new cluster at the identical committed offset, so it reprocesses nothing and skips nothing - zero-downtime cutover. Open at this step: step 4, Cutover - promote_mirror, no reprocessing
The takeaway
Because the link preserves offsets and syncs committed positions 1:1, “resume where you left off” is the identical position on the new cluster - a cutover with no reprocessing and no gap, unlike MM2 which re-produces records and must translate offsets.
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=12.0.3" title="Kafka Simulator: Capstone: migrate a cluster with Cluster Linking, zero downtime" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/migrate-with-cluster-linking/">Zero-downtime Kafka migration with Confluent Cluster Linking</a></p>