Kafka MirrorMaker 2 Config Generator
A MirrorMaker 2 configuration, and what your topics are called on the target. The default policy renames all of them, which is the most common surprise.
mm2.properties
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Not expecting topics to be renamed
The default replication policy prefixes every topic with the source cluster alias, so orders becomes primary.orders on the target. Consumers pointed at the old name find nothing.
Instead:Either expect the prefix or set a custom replication policy, knowing that an identity policy makes loops possible.
Enabling bidirectional replication with the identity policy
Without the prefix there is nothing to stop a record replicating back and forth indefinitely.
Instead:Keep the default policy for active-active, or implement loop prevention deliberately.
Assuming offsets translate automatically
Offset translation needs the checkpoint connector enabled and the consumer to use the translation, otherwise a failover starts from the wrong position.
Instead:Enable checkpoints and use RemoteClusterUtils, or accept reprocessing.
What MirrorMaker 2 does to your topic names, and why
The renaming is not a quirk. It is the mechanism that stops bidirectional replication looping.
DefaultReplicationPolicy prefixes everything
A topic called orders on the source arrives as us-east.orders on the target. A consumer pointed at orders on the target finds an empty or non-existent topic, and this is the single most common MirrorMaker 2 surprise. The prefix is what makes the loop protection work: a mirrored topic already carries a prefix, so it is never mirrored back.
IdentityReplicationPolicy keeps the name and removes the protection
For an active-passive failover where consumers must move across without being reconfigured, identity naming is what you want. It also means bidirectional replication copies a record back and forth forever, because nothing in the record marks it as already mirrored. Either use the default policy or make each topic owned by exactly one cluster and enforce it with the topics pattern.
The topics setting is a Java regex
Not a glob. `orders.*` matches orders, orders-eu and ordersomething, because a dot matches any character. And `orders*` is not a prefix match at all: in a regex it means the letters `order` followed by any number of `s`. Use `orders-.*` for a prefix and escape a literal dot.
Offset translation is approximate and needs checkpoints
Checkpoints record the source-to-target offset mapping at intervals, and the group offset sync writes the translation into the target's committed offsets. Turning the sync on without checkpoints silently does nothing, because the mapping it reads is never produced. Even with both, a consumer moved across resumes near where it was rather than exactly, which is at-least-once across a failover.
It is a Connect cluster, so everything about Connect applies
It needs credentials for both clusters, its internal topics matter, and a connector can report RUNNING while its tasks have failed. It also replicates data and not ACLs by default, so a target cluster with all the topics and none of the permissions is a normal outcome rather than a mistake.