Monedula

Scenario 10.2.5 · Bidirectional links and clean failback

Kafka failover and failback with Confluent Cluster Linking

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

Cluster Linking is offset-preserving, so you can switch the active cluster over to the mirror and later switch BACK - the link reverses in place and offsets stay consistent end to end, with no reprocess window.

Run this scenario in the playground

Offsets consistent end to end. t+2.200s

O5 produced on the restored primary lands at offset 4 and is mirrored forward to primary.orders at the SAME offset 4. Both copies now hold offsets 0..4 identically - no reprocess window, no data loss.

Open at this step: step 6, Offsets consistent end to end

What you start with

Because Cluster Linking copies records at identical offsets, failover can be clean and reversible: promote the mirror to writable (switchover), produce on it, then later promote the original back (switchback). Each switch reverses the link in place, and no offsets are ever remapped.

Step by step

  1. One cluster link, primary → dr t+0.000s A cluster link mirrors orders from primary into the read-only mirror primary.orders on dr. Cluster Linking is offset-preserving, so the mirror will hold the same records at the same offsets. The prefixed name is a simulator label: Confluent's reverse commands refuse prefixed links, so a reversible mirror is called orders on both sides. Open at this step: step 1, One cluster link, primary → dr
  2. Forward mirror (offset-preserving) t+0.700s Three records on orders (primary) are mirrored byte-for-byte into primary.orders (dr) at identical offsets - both at high-watermark 3. primary.orders is a read-only mirror. Open at this step: step 2, Forward mirror (offset-preserving)
  3. Switchover: promote + reverse t+1.050s switch_cluster_link promotes primary.orders to writable on dr, DEMOTES orders to a read-only mirror on primary, and reverses the link in place (dr → primary) so it mirrors back into the original orders topic. Open at this step: step 3, Switchover: promote + reverse
  4. Produce on the new primary; mirror back t+1.500s A dr-local producer appends O4 to the promoted primary.orders at offset 3. The reversed link mirrors it back into orders on primary at the SAME offset 3 - both at high-watermark 4. Open at this step: step 4, Produce on the new primary; mirror back
  5. Switchback: promote + reverse again t+1.750s switch_cluster_link promotes orders back to writable on primary, demotes primary.orders to a read-only mirror on dr, and reverses the link forward again (primary → dr). Open at this step: step 5, Switchback: promote + reverse again
  6. Offsets consistent end to end t+2.200s O5 produced on the restored primary lands at offset 4 and is mirrored forward to primary.orders at the SAME offset 4. Both copies now hold offsets 0..4 identically - no reprocess window, no data loss. Open at this step: step 6, Offsets consistent end to end

The takeaway

After a full switchover and switchback both clusters hold the same records at the same offsets - there is no reprocess window and no data loss. Offset preservation is what makes Cluster Linking failover and failback clean and bidirectional.

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.5" title="Kafka Simulator: Bidirectional links and clean failback" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/bidirectional-links-failback/">Kafka failover and failback with Confluent Cluster Linking</a></p>

Further reading

Confluent documentation

More in Disaster recovery

All scenarios