Kafka Mirroring vs Replication: What's the Difference?
Kafka mirroring vs replication is a vocabulary question before it is an architecture question. In Kafka's own terms, replication copies partitions between brokers inside a single cluster. Mirroring copies topics from one cluster to another — the job MirrorMaker is named for. Both mechanisms produce copies of your data. They run in different places, protect against different failures, and in production you usually need both.
This post pins down where each term comes from and compares the two mechanisms side by side. It also shows why the copy neither of them makes — immutable, outside every cluster — still has to come from somewhere else.
Replication is the broker-internal mechanism that keeps identical partition copies inside one cluster. Mirroring is an external process that re-produces topics into a second cluster. One guards brokers, the other guards regions — and neither one is a backup.
Where the two terms come from
Apache Kafka's documentation uses the word "replication", unqualified, for one thing: the intra-cluster mechanism that keeps multiple copies of each partition on different brokers. That is the replication you configure with a replication factor and monitor through in-sync replicas.
Copying data between clusters gets its own chapter, titled "Geo-Replication (Cross-Cluster Data Mirroring)". The docs draw the line explicitly: "This inter-cluster replication is different from Kafka's intra-cluster replication, which replicates data within the same Kafka cluster." Mirroring is the historical Kafka word for that cross-cluster job, and it survives in the tool's name: MirrorMaker. Kafka 4.0 removed the original version (deprecated by KIP-720), so MirrorMaker 2 is the only one left.
Vendor naming is where the vocabulary blurs. Confluent Replicator, AWS MSK Replicator, and Uber's uReplicator all perform cross-cluster mirroring under a "replication" brand name. The Replicator vs MirrorMaker comparison covers how two of them differ. Confluent's Cluster Linking blurs it from the other side: a broker-native mirror that copies partitions byte-for-byte with offsets preserved, no Connect cluster involved. They are real tools solving real problems, but their names are why "replication" now means two things in most Kafka conversations.
Kafka mirroring vs replication at a glance
The kafka mirroring vs replication distinction comes down to who makes the copy and what the copy is. Replication is the brokers copying among themselves; mirroring is a separate pipeline reading from one cluster and writing to another.
| Dimension | Replication (intra-cluster) | Mirroring (cross-cluster) |
|---|---|---|
| What runs the copy | The brokers themselves — followers fetch from the partition leader | A separate process, typically MirrorMaker 2 on Kafka Connect |
| Copy mechanism | Followers append the leader's log in identical order | Records are consumed from the source and re-produced to the target |
| Record offsets | Identical on every replica | Assigned fresh by the target cluster — offsets differ |
| Topic identity | Same topic; clients never see replicas | A distinct topic on the target, often renamed (orders → primary.orders) |
| Consumer offsets | Unchanged — one cluster, one log | Must be translated between clusters |
| Configured by | --replication-factor per topic | Tool configuration: cluster aliases, topic filters, sync intervals |
| Ships with the broker | Yes, always on | No — deployed and operated separately |
Two rows cause most of the confusion. First, offsets: a replica is the same log, so offset 4,215 means the same record on every broker. A mirrored topic is a different log, so the same record lands at a different offset on the target. Second, topic identity: replication is invisible to clients, while mirroring creates real, separately named topics that consumers must know about.
Replication: copies inside one cluster
Replication keeps each partition alive when the hardware under it dies. You set a replication factor — three is the standard baseline — and Kafka places that many copies of each partition on different brokers. One copy leads, the others follow by fetching the leader's log, and the followers that stay current form the in-sync replica set (ISR).
A healthy replicated partition looks like this in kafka-topics.sh --describe output:
Topic: orders Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Three brokers hold the copy and all three are in sync. If broker 1 fails, the cluster elects a new leader from the ISR within seconds. Clients reconnect to the same topic at the same offsets. Nothing about the failure is visible in the data.
That transparency is the point — and the boundary. Replication protects against broker, disk, and rack loss inside one cluster's failure domain. Kafka replication explained covers the mechanics in depth: acknowledgements, min.insync.replicas, leader election. The beginner's guide walks through it one message at a time.
Mirroring: copies between clusters
Mirroring copies topics into a different cluster, usually in a different data center or region. MirrorMaker 2 runs on the Kafka Connect framework: it consumes records from the source cluster and re-produces them to the target. Per the Kafka documentation, it replicates topics, topic configurations, consumer groups and their offsets, and ACLs.
Because records are re-produced rather than copied byte for byte, the target broker assigns new offsets. A consumer position that means "caught up" on the source points somewhere else on the mirror. MM2 therefore ships a checkpoint mechanism to translate consumer offsets — MirrorMaker 2 offset sync covers how it works and where it is approximate. Mirrored topics also usually carry their source cluster's name as a prefix, so orders from cluster primary arrives as primary.orders.
Mirroring's failure domain is the whole cluster: a region outage, a data-center loss, or a cluster you are migrating away from. It also handles jobs replication never touches, like aggregating several clusters into one or feeding a read-only analytics cluster. The Kafka-to-Kafka replication guide shows a working MM2 flow, and the geo-replication patterns post maps the common topologies.
Different failure domains, different jobs
Mirroring and replication are not alternatives, and you do not pick one. Replication is not optional — every production topic needs a replication factor of at least three, on the source cluster and on any mirror. Mirroring is additive: you deploy it when a second cluster needs the data, for disaster recovery, migration, locality, or aggregation.
The clean way to reason about it is by what fails:
- A broker or disk dies. Replication handles it. Leader election promotes an in-sync follower, and clients continue at the same offsets.
- A cluster, data center, or region dies. Mirroring handles it. Applications switch to the mirror cluster, with offset translation repositioning consumers.
- The data itself goes bad — a bad deploy writes corrupt records, someone deletes a topic, a misconfigured retention policy purges early. Neither mechanism helps, because both copied the damage faithfully.
That third failure class is the one both mechanisms share, and it deserves its own section.
Neither one is a backup
Replication and mirroring both follow the live log. That is their job: every write on the source, good or bad, reaches every replica and every mirror within seconds. Corruption replicates. Deletes mirror. Shortly after an incident, all of your copies agree on the damage, which is why replication is not backup — and mirroring is not either.
A backup is a different kind of copy: independent of every cluster, immutable once written, and restorable to a point in time. OSO Kafka Backup writes compressed topic data and consumer group offsets to S3, Azure Blob, GCS, or a filesystem — storage no broker can touch. It restores any topic to any millisecond, including topics that no longer exist. In a disaster recovery design, it covers the failure class the other two copies structurally cannot: the one where the log itself is wrong. For a direct comparison with mirroring, see OSO Kafka Backup vs MirrorMaker 2.
Frequently asked questions
Frequently asked questions
Is Kafka mirroring the same as replication?
No. In Kafka terminology, replication copies partitions between brokers inside one cluster and is built into the broker. Mirroring copies topics between separate clusters using an external tool such as MirrorMaker 2. The Kafka documentation explicitly distinguishes intra-cluster replication from cross-cluster mirroring.
What is mirroring in Kafka?
Mirroring is Kafka's term for copying topic data from one cluster to another — the documentation titles it Cross-Cluster Data Mirroring. MirrorMaker 2 performs it by consuming records from the source cluster and re-producing them to the target, along with topic configurations, consumer groups, and ACLs.
Do mirrored Kafka topics keep the same offsets?
Not with MirrorMaker 2. It re-produces records, so the target cluster assigns new offsets, and a record can sit at a different offset on the mirror — which is why MM2 includes offset translation for consumer positions. Confluent Cluster Linking is the exception: it copies partitions byte-for-byte and preserves offsets exactly.
Can mirroring replace replication inside a Kafka cluster?
No. Mirroring depends on each cluster's own replication for durability — a mirror cluster with replication factor 1 loses data the moment one of its brokers fails. Keep the replication factor at three on the source and on every mirror, and use mirroring only for cross-cluster goals.
Does Kafka mirroring count as a backup?
No. A mirror follows the live log, so corrupt records, accidental deletes, and bad producer deploys propagate to it within seconds. A backup is an immutable, point-in-time copy stored outside every cluster, which is what lets you restore data to a moment before the damage.
Conclusion
The two words describe two copies with two jobs. Replication is the broker-internal copy that keeps the same log identical across brokers — same topic, same offsets, invisible failover when hardware dies. Mirroring is the external copy that re-produces topics into another cluster — new offsets, usually new names, and a place to run when a region dies. Run both, and there is still one copy missing: the immutable one that survives the failures they share.
Replication guards brokers and mirroring guards regions — OSO Kafka Backup guards the data itself, with immutable point-in-time copies in your own object storage. Get started or see how it compares to MirrorMaker 2.