// This module is included in:
//
// overview/assembly-configuration-points.adoc

[id="con-overview-mm2-{context}"]
= MirrorMaker 2.0 configuration

[role="_abstract"]
MirrorMaker 2.0 consumes messages from a source Kafka cluster and writes them to a target Kafka cluster.

MirrorMaker 2.0 uses:

* Source cluster configuration to consume data from the source cluster
* Target cluster configuration to output data to the target cluster

MirrorMaker 2.0 is based on the Kafka Connect framework, _connectors_ managing the transfer of data between clusters.

You configure MirrorMaker 2.0 to define the Kafka Connect deployment, including the connection details of the source and target clusters, and then run a set of MirrorMaker 2.0 connectors to make the connection.

MirrorMaker 2.0 consists of the following connectors:

`MirrorSourceConnector`:: The source connector replicates topics from a source cluster to a target cluster. It also replicates ACLs and is necessary for the `MirrorCheckpointConnector` to run. 
`MirrorCheckpointConnector`:: The checkpoint connector periodically tracks offsets. If enabled, it also synchronizes consumer group offsets between the source and target cluster.
`MirrorHeartbeatConnector`:: The heartbeat connector periodically checks connectivity between the source and target cluster.

NOTE: If you are using the User Operator to manage ACLs, ACL replication through the connector is not possible.    

The process of _mirroring_ data from a source cluster to a target cluster is asynchronous.
Each MirrorMaker 2.0 instance mirrors data from one source cluster to one target cluster. 
You can use more than one MirrorMaker 2.0 instance to mirror data between any number of clusters.

.Replication across two clusters
image::mirrormaker.png[MirrorMaker 2.0 replication]

By default, a check for new topics in the source cluster is made every 10 minutes.
You can change the frequency by adding `refresh.topics.interval.seconds` to the source connector configuration.

== Cluster configuration

You can use MirrorMaker 2.0 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.0 cluster is required at each target destination.

== Bidirectional replication (active/active)

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

Each cluster replicates the data of the other cluster using the concept of _source_ and _remote_ topics.
As the same topics are stored in each cluster, remote topics are automatically renamed by MirrorMaker 2.0 to represent the source cluster.
The name of the originating cluster is prepended to the name of the topic.

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

By flagging the originating cluster, topics are not replicated back to that cluster.

The concept of replication through _remote_ topics is useful when configuring an architecture that requires data aggregation.
Consumers can subscribe to source and remote topics within the same cluster, without the need for a separate aggregation cluster.

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

The MirrorMaker 2.0 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.