Kafka Replicator vs MirrorMaker: Which Replication Tool Fits?
The Kafka Replicator vs MirrorMaker decision comes down to ownership. MirrorMaker 2 is the replication framework included with Apache Kafka: free, vendor-neutral, and built on Kafka Connect. Kafka Replicator — almost always Confluent Replicator — is Confluent's commercial connector with deeper Confluent Platform integration, including Schema Registry migration and Control Center monitoring.
The feature lists overlap heavily. The real differences sit in licensing, destination topic naming, consumer offset translation, and schema handling. Neither tool can restore yesterday's data, so neither replaces backup.
Choose MirrorMaker 2 for vendor-neutral estates and non-Java consumers. Keep Confluent Replicator where a supported Confluent Platform deployment already justifies it — and evaluate Cluster Linking first for new Confluent designs. Pair either with independent backup for recovery to an earlier state.
Kafka Replicator vs MirrorMaker at a glance
A quick naming check prevents confusion. "Kafka Replicator" in search results and vendor material almost always means Confluent Replicator. MirrorMaker 1 is legacy; the current Apache tool is MirrorMaker 2 (MM2), rebuilt on Kafka Connect. A useful comparison today is MM2 against Confluent Replicator.
| Dimension | MirrorMaker 2 | Confluent Replicator |
|---|---|---|
| License and cost | Apache 2.0, ships with Kafka | Commercial, Confluent Platform license |
| Runs on | Any reachable Kafka; dedicated mode or a Connect cluster | Connect cluster in a Confluent Platform deployment |
Default destination name for orders | primary.orders (source alias prefix) | orders (topic.rename.format default ${topic}) |
| Loop prevention | Structural, through the naming policy | Optional provenance headers, default off |
| Consumer offset translation | Checkpoints; optional write to target __consumer_offsets | Timestamp interceptor for Java consumers |
| Topic config sync | Yes, with filters | Yes, with filters |
| Schema Registry handling | None — schema topics copy as bytes | Schema migration between registries |
| Monitoring | JMX metrics into your own stack | Control Center plus JMX |
| Support | Community | Confluent support |
The rest of this article walks through the dimensions where the tools genuinely diverge. For depth on either side, see the Kafka Replicator guide and the MirrorMaker overview.
Same skeleton, different ownership
Both tools are Kafka Connect source-connector designs. A consumer reads selected source topics, Connect tasks hand records to a producer, and the producer writes to the destination cluster. Both deliver at-least-once, so a restart can duplicate records. Both are asynchronous, so lag is a normal operating fact rather than a defect.
MirrorMaker 2 splits the work across three cooperating connectors:
MirrorSourceConnector for records, MirrorCheckpointConnector for consumer
positions, and MirrorHeartbeatConnector for path liveness. It runs in a
dedicated mode through connect-mirror-maker.sh or on an existing Connect
cluster. You own the workers, their capacity, and their upgrades, on any Kafka
you can reach — self-managed, MSK, or anything else that speaks the protocol.
Confluent Replicator is a single commercial connector, with an executable wrapper as an alternative packaging. Confluent recommends running its workers near the destination cluster, and the connector lives inside a licensed Confluent Platform deployment with a defined compatibility matrix. The MirrorMaker 2 setup tutorial and the Replicator guide cover deployment details for each.
Topic naming and loop prevention
Naming is the sharpest behavioral difference, and it decides how much work a failover cutover requires.
MirrorMaker 2's DefaultReplicationPolicy prefixes every remote topic with
its source cluster alias. Topic orders replicated from cluster primary
becomes primary.orders on the target. Origin stays visible, and a record
cannot cycle back, because each hop would create a new, distinct name.
The cost appears at cutover: consumers must switch to remote topic names, or
your applications must handle both.
Apache Kafka also ships IdentityReplicationPolicy, which keeps topic names
unchanged. Its own source documentation carries the caveat that MirrorMaker
cannot prevent replication cycles under this policy, so the topology must stay
acyclic by design. That is an honest tradeoff, not a loophole.
Confluent Replicator defaults the other way. Its topic.rename.format
default of ${topic} keeps the source name, which makes consumer cutover
transparent. Confluent's own configuration reference recommends giving each
source cluster a distinct prefix or suffix when several replicate into one
destination, to avoid name collisions. For bidirectional flows, Replicator
relies on provenance headers — provenance.header.enable defaults to
false, and consumers that process headers must skip the __replicator_id
key once it is on.
| Policy | Destination name for orders | Cycle-safe by design | Consumer cutover effort |
|---|---|---|---|
MM2 DefaultReplicationPolicy | primary.orders | Yes | Applications must adopt remote names |
MM2 IdentityReplicationPolicy | orders | No — topology must be acyclic | None for topic names |
Replicator ${topic} default | orders | Needs provenance headers when bidirectional | None for topic names |
Consumer offset translation
The same record almost never sits at the same offset in two clusters, so committed positions cannot be copied as raw numbers. Each tool translates positions differently, and the difference matters most in polyglot estates.
MirrorMaker 2 records source-to-target offset pairs in an internal
offset-syncs topic and turns them into per-group checkpoints on the target.
With sync.group.offsets.enabled=true — the default is false — it writes
translated positions straight into the target's __consumer_offsets, for
groups with no active members there. This works for any client that commits
offsets to Kafka, with no application change. The
MirrorMaker 2 offset sync guide
covers the internals and failure modes.
Confluent Replicator translates by timestamp instead. A consumer interceptor
records group positions and timestamps in the source __consumer_timestamps
topic, and Replicator maps them to destination offsets while the group is
inactive. The interceptor path supports Java consumers; applications on other
clients need a separately tested position plan. Replicator also never copies
the internal __consumer_offsets or __transaction_state topics, even when
a topic filter matches them.
If your consumers span Python, Go, and .NET, MM2's checkpoint model is the lower-risk path. If your consumers are Java and already run Confluent interceptors, Replicator's translation fits naturally.
Schemas, monitoring, and the license line
Schema Registry handling separates the tools cleanly. Replicator can migrate schemas between registries, whether self-managed or Confluent Cloud, which makes it useful for environment moves inside a Confluent estate. MirrorMaker 2 has no registry awareness: schema topics replicate as bytes like any other topic, which works but migrates nothing intelligently. Protecting registry state is its own problem either way — the Schema Registry backup guide covers it.
Monitoring follows the same split. MM2 exposes Connect and JMX metrics that you wire into your own Prometheus and Grafana stack. Replicator adds Control Center visibility for teams already operating Confluent Platform.
Then there is the license itself. MirrorMaker 2 is Apache 2.0 and ships in every Kafka distribution. Replicator requires a Confluent Platform license. Free is not zero-cost, though: MM2 still consumes worker capacity, monitoring effort, and upgrade engineering that a supported commercial product partly absorbs. Price the operations, not just the download.
Which should you choose?
Pick by estate and client mix rather than by feature count:
- Vendor-neutral Kafka — self-managed, MSK, or mixed estates: MirrorMaker 2. It runs anywhere, costs no license, and its checkpoint translation works across client languages.
- An existing, supported Confluent Platform estate running Replicator: keep it. Migration engineering rarely pays back while the deployment stays supported.
- A new cross-cluster design inside Confluent: evaluate Cluster Linking first. Confluent's Replicator overview states that Cluster Linking and Schema Linking are preferred for most new use cases, with Replicator remaining relevant to specific migration paths.
- Polyglot consumers that need automated failover positions: MirrorMaker 2, for its client-neutral offset sync.
- Schema migration between registries: Replicator.
On AWS MSK, the managed sibling is MSK Replicator, which runs MM2-style replication as a service — the MSK Replicator guide covers when that managed tradeoff makes sense.
Neither one is a backup
Whichever tool wins your comparison, it copies the live stream forward. A bad write, an application bug, or a topic deletion replicates as faithfully as good data. Both copies remain inside running Kafka clusters, subject to broker retention and administrative mistakes. Neither tool can reconstruct a topic as it existed before an incident.
Recovery to an earlier state needs a restore point outside the replication path. OSO Kafka Backup stores topic data and consumer group offsets together in S3, S3-compatible storage, Azure Blob, GCS, or a filesystem, with millisecond-precision point-in-time recovery and offset preservation built in, under an MIT license. The direct feature boundaries are mapped in OSO Kafka Backup vs Confluent Replicator and OSO Kafka Backup vs MirrorMaker.
Whichever replicator you run, it copies mistakes as faithfully as records. Keep point-in-time restore points — topic data and consumer offsets — in your own object storage. Start with OSO Kafka Backup, and see how it fits a disaster recovery design.
The comparison, settled
MirrorMaker 2 suits vendor-neutral estates: it ships with Kafka, runs anywhere, and translates offsets for any committing client. Confluent Replicator earns its license where Confluent Platform, Schema Registry migration, and Control Center already anchor the operating model — with Cluster Linking as the first option to assess for new Confluent designs. Whichever replicates your topics, pair it with independent backup, because replication forwards failures instead of preventing them.
Frequently asked questions
Is Confluent Replicator the same as Kafka MirrorMaker?
No. Both replicate topics between Kafka clusters using Kafka Connect, but MirrorMaker 2 is open source and included with Apache Kafka, while Confluent Replicator is a commercial connector licensed as part of Confluent Platform with Schema Registry and Control Center integration.
Does MirrorMaker 2 rename replicated topics?
By default, yes. The DefaultReplicationPolicy prefixes each remote topic with its source cluster alias, so orders from cluster primary becomes primary.orders. The IdentityReplicationPolicy keeps names unchanged, but MirrorMaker then cannot prevent replication cycles, so the topology must stay acyclic.
Can MirrorMaker 2 or Confluent Replicator restore deleted Kafka data?
No. Both tools copy the live stream forward, so deletions, bad writes, and application bugs replicate to the destination like valid events. Recovering an earlier state requires an independent backup with retained restore points outside the replication path.
How do consumer offsets move between clusters in each tool?
MirrorMaker 2 records offset pairs in an internal offset-syncs topic, emits per-group checkpoints, and can write translated positions to the target cluster for inactive groups, regardless of client language. Confluent Replicator translates by timestamp using a Java consumer interceptor that writes to the __consumer_timestamps topic.
Should new Confluent deployments use Replicator or Cluster Linking?
Confluent's documentation states that Cluster Linking and Schema Linking are preferred for most new use cases. Replicator remains relevant for supported existing deployments and specific migration paths, so new Confluent cross-cluster designs should assess Cluster Linking first.