:_mod-docs-content-type: CONCEPT

// This module is included in:
//
// assembly-config.adoc

[id="con-overview-mm2-{context}"]
= About MirrorMaker 2

[role="_abstract"]
Kafka MirrorMaker 2 replicates data (topics, consumer groups, and offsets) between Kafka clusters. 
Through configuration, you define source and target cluster connections.
You can use MirrorMaker 2 in _active/passive_ or _active/active_ cluster configurations.

active/active cluster configuration:: An active/active configuration has two active clusters replicating data bidirectionally. Applications can use either cluster. Each cluster can provide the same data. In this way,  you can make the same data available in different geographical locations. As consumer groups are active in both clusters, consumer offsets for replicated topics are not synchronized back to the source cluster. 
active/passive cluster configuration:: An active/passive configuration has an active cluster replicating data to a passive cluster. The passive cluster remains on standby. You might use the passive cluster for data recovery in the event of system failure.

The expectation is that producers and consumers connect to active clusters only.
A MirrorMaker 2 cluster is required at each target destination.

NOTE: In most deployments, write operations should be made only to source topics. 
Write operations on target topics are not prevented, but they can cause conflicts and should be avoided.

== Bidirectional replication (active/active)

The MirrorMaker 2 architecture supports bidirectional replication in an _active/active_ cluster configuration.

Each cluster replicates the other's data using the concept of _source_ and _remote_ topics.
In this context, _remote_ refers to the target cluster receiving replicated data from the perspective of the source MirrorMaker instance.
Each cluster simultaneously acts as both source and remote, depending on the direction of the replication flow.

As the same topics are stored in each cluster, remote topics are automatically renamed by MirrorMaker 2 to indicate their origin.
The name of the source cluster is prepended to the topic name.

.Topic renaming
image::mirrormaker-renaming.png[MirrorMaker 2 bidirectional architecture]

This renaming prevents topics from being replicated back to their originating cluster.

This replication structure also supports data aggregation in active/active setups: 
Consumers can subscribe to both source and remote topics within the same cluster, eliminating the need for a separate aggregation cluster.

[id=unidirectional_replication_activepassive]
== Unidirectional replication (active/passive)

The MirrorMaker 2 architecture supports unidirectional replication in an _active/passive_ cluster configuration.

You can use an _active/passive_ cluster configuration to make backups or migrate data to another cluster.
In this situation, you might not want automatic renaming of remote topics.

You can override automatic renaming by adding `IdentityReplicationPolicy` to the source connector configuration.
With this configuration applied, topics retain their original names.