Multi-Cluster and Disaster Recovery

Key points

• MirrorMaker 2 is built on Connect: it consumes from one cluster and produces to another, carrying topic configs and ACLs with it.
• Replication is asynchronous. Whatever has not been copied when the primary dies is gone, and that gap is your RPO.
• Offsets do not line up between clusters. MM2 writes a checkpoints topic so a group can resume near the right place, not exactly on it.
• Remote topics are prefixed (primary.orders). IdentityReplicationPolicy drops it, losing loop protection.
• Active/passive is a realistic DR plan. Active/active needs per-key conflict handling and is usually pinned by region.
• Rehearse the failover. An untested DR cluster is an expensive backup that nobody has ever restored.

Example

# connect-mirror-maker.properties
clusters=primary, dr
primary.bootstrap.servers=kafka-primary:9092
dr.bootstrap.servers=kafka-dr:9092

# one direction only: primary -> dr
primary->dr.enabled=true
primary->dr.topics=orders|payments|customers
dr->primary.enabled=false

# so a consumer group can resume on the DR side
primary->dr.emit.checkpoints.enabled=true
sync.group.offsets.enabled=true

replication.factor=3
checkpoints.topic.replication.factor=3

# topics arrive as "primary.orders" unless you switch to
# replication.policy.class=org.apache.kafka.connect.mirror.IdentityReplicationPolicy

Async replication always loses the tail. Decide up front how many seconds you can afford to lose.