Home / Data Platform / Streaming & CDC

Data PlatformHow-toAdvanced

Kafka cross-region DR with MirrorMaker 2: topics, offsets and failover

Replicate Kafka topics and consumer group offsets to a DR cluster with MirrorMaker 2. Covers naming policies, offset translation, monitoring lag, and a consumer failover runbook.

Deepak Bhardwaj2 min read

Applies toApache Kafka 3.x/4.x MirrorMaker 2 (Kafka Connect based); Amazon MSK Replicator and Confluent Cluster Linking are managed alternatives

Pattern: active-passive

Producers and consumers use the primary cluster. MirrorMaker 2 (MM2) runs near the DR cluster and copies topics, configs and consumer offsets from the primary into DR. On failover, clients switch to DR.

1. MM2 configuration (dedicated mode)

# mm2.properties
clusters = primary, dr
primary.bootstrap.servers = kafka-p1:9092,kafka-p2:9092,kafka-p3:9092
dr.bootstrap.servers = kafka-d1:9092,kafka-d2:9092,kafka-d3:9092

primary->dr.enabled = true
primary->dr.topics = orders.*, payments.*
primary->dr.groups = .*

replication.factor = 3
sync.topic.configs.enabled = true
sync.group.offsets.enabled = true
sync.group.offsets.interval.seconds = 30
emit.checkpoints.interval.seconds = 30

# keep the same topic names in DR (instead of "primary.orders")
replication.policy.class = org.apache.kafka.connect.mirror.IdentityReplicationPolicy

connect-mirror-maker.sh mm2.properties

Run 2+ MM2 instances for HA (they share work through Connect).

Note

The default policy prefixes topics with the source alias (primary.orders), which is safer for active-active setups. IdentityReplicationPolicy keeps names the same, which is simpler for active-passive. Don't use it if replication goes both ways, or you'll create loops.

2. Offset translation

Offsets differ between clusters. MM2 writes checkpoints and, with sync.group.offsets.enabled, commits the translated offsets for groups that are not active on DR. After failover, consumers resume near where they stopped. Expect some duplicates, so consumers must be idempotent.

3. Monitoring

  • Replication lag: the MM2 metric replication-latency-ms and per-partition record lag.
  • MM2 Connect task status (all tasks RUNNING).
  • Alert if lag goes over your RPO (for example 60 seconds).

4. Failover runbook

  1. Confirm the primary is down, or declare DR.
  2. Stop MM2. The primary is gone, or you want to stop copying.
  3. Point consumers at DR first. They pick up the synced group offsets.
  4. Point producers at DR (change bootstrap servers in config or DNS).
  5. Verify consumer lag and the end-to-end flow.

5. Failback

Set up MM2 in the reverse direction (dr → primary), wait until it catches up, then switch consumers and producers back in the same order. Then restore the original direction.

Managed alternatives

  • Amazon MSK Replicator: managed replication between MSK clusters, with offset sync.
  • Confluent Cluster Linking: byte-for-byte mirror topics that keep the same offsets, so no translation is needed.

Tip

Producers that use transactions or exactly-once semantics don't get exactly-once across clusters. Design consumers to handle replays from a short window after failover.

Related fixes