// Module included in the following assemblies:
//
// assembly-mirrormaker.adoc

[id='proc-mirrormaker-replication-{context}']
= Synchronizing data between Kafka clusters using MirrorMaker 2.0

Use MirrorMaker 2.0 to synchronize data between Kafka clusters through configuration.

The configuration must specify:

* Each Kafka cluster
* Connection information for each cluster, including TLS authentication
* The replication flow and direction
** Cluster to cluster
** Topic to topic

Use the properties of the `KafkaMirrorMaker2` resource to configure your Kafka MirrorMaker 2.0 deployment.

NOTE: The previous version of MirrorMaker continues to be supported.
If you wish to use the resources configured for the previous version,
they must be updated to the format supported by MirrorMaker 2.0.

MirrorMaker 2.0 provides default configuration values for properties such as replication factors.
A minimal configuration, with defaults left unchanged, would be something like this example:

[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersionPrev}
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: {DefaultKafkaVersion}
  connectCluster: "my-cluster-target"
  clusters:
  - alias: "my-cluster-source"
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092
  - alias: "my-cluster-target"
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092
  mirrors:
  - sourceCluster: "my-cluster-source"
    targetCluster: "my-cluster-target"
    sourceConnector: {}
----

You can configure access control for source and target clusters using TLS or SASL authentication.
This procedure shows a configuration that uses TLS encryption and authentication for the source and target cluster.

.Prerequisites

* See the _Deploying Strimzi_ guide for instructions on running a:
** link:{BookURLDeploying}#cluster-operator-str[Cluster Operator^]
** link:{BookURLDeploying}#deploying-kafka-cluster-str[Kafka cluster^]
* Source and target Kafka clusters must be available

.Procedure

. Edit the `spec` properties for the `KafkaMirrorMaker2` resource.
+
The properties you can configure are shown in this example configuration:
+
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersionPrev}
kind: KafkaMirrorMaker2
metadata:
  name: my-mirror-maker2
spec:
  version: {DefaultKafkaVersion} <1>
  replicas: 3 <2>
  connectCluster: "my-cluster-target" <3>
  clusters: <4>
  - alias: "my-cluster-source" <5>
    authentication: <6>
      certificateAndKey:
        certificate: source.crt
        key: source.key
        secretName: my-user-source
      type: tls
    bootstrapServers: my-cluster-source-kafka-bootstrap:9092 <7>
    tls: <8>
      trustedCertificates:
      - certificate: ca.crt
        secretName: my-cluster-source-cluster-ca-cert
  - alias: "my-cluster-target" <9>
    authentication: <10>
      certificateAndKey:
        certificate: target.crt
        key: target.key
        secretName: my-user-target
      type: tls
    bootstrapServers: my-cluster-target-kafka-bootstrap:9092 <11>
    config: <12>
      config.storage.replication.factor: 1
      offset.storage.replication.factor: 1
      status.storage.replication.factor: 1
      ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" <13>
      ssl.enabled.protocols: "TLSv1.2"
      ssl.protocol: "TLSv1.2"
      ssl.endpoint.identification.algorithm: HTTPS <14>
    tls: <15>
      trustedCertificates:
      - certificate: ca.crt
        secretName: my-cluster-target-cluster-ca-cert
  mirrors: <16>
  - sourceCluster: "my-cluster-source" <17>
    targetCluster: "my-cluster-target" <18>
    sourceConnector: <19>
      config:
        replication.factor: 1 <20>
        offset-syncs.topic.replication.factor: 1 <21>
        sync.topic.acls.enabled: "false" <22>
        replication.policy.separator: "" <23>
        replication.policy.class: "io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy" <24>
    heartbeatConnector: <25>
      config:
        heartbeats.topic.replication.factor: 1 <26>
    checkpointConnector: <27>
      config:
        checkpoints.topic.replication.factor: 1 <28>
    topicsPattern: ".*" <29>
    groupsPattern: "group1|group2|group3" <30>
  resources: <31>
    requests:
      cpu: "1"
      memory: 2Gi
    limits:
      cpu: "2"
      memory: 2Gi
  logging: <32>
    type: inline
    loggers:
      connect.root.logger.level: "INFO"
  readinessProbe: <33>
    initialDelaySeconds: 15
    timeoutSeconds: 5
  livenessProbe:
    initialDelaySeconds: 15
    timeoutSeconds: 5
  jvmOptions: <34>
    "-Xmx": "1g"
    "-Xms": "1g"
  image: my-org/my-image:latest <35>
  template: <36>
    pod:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: application
                    operator: In
                    values:
                      - postgresql
                      - mongodb
              topologyKey: "kubernetes.io/hostname"
    connectContainer: <37>
      env:
        - name: JAEGER_SERVICE_NAME
          value: my-jaeger-service
        - name: JAEGER_AGENT_HOST
          value: jaeger-agent-name
        - name: JAEGER_AGENT_PORT
          value: "6831"
  tracing:
    type: jaeger <38>
  externalConfiguration: <39>
    env:
      - name: AWS_ACCESS_KEY_ID
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsAccessKey
      - name: AWS_SECRET_ACCESS_KEY
        valueFrom:
          secretKeyRef:
            name: aws-creds
            key: awsSecretAccessKey
----
<1> The Kafka Connect xref:type-KafkaConnectSpec-reference[version].
<2> xref:con-common-configuration-replicas-reference[The number of replica nodes].
<3> xref:type-KafkaMirrorMaker2Spec-reference[Cluster alias] for Kafka Connect.
<4> xref:type-KafkaMirrorMaker2ClusterSpec-reference[Specification] for the Kafka clusters being synchronized.
<5> xref:type-KafkaMirrorMaker2ClusterSpec-reference[Cluster alias] for the source Kafka cluster.
<6> Authentication for the source cluster, using the xref:type-KafkaClientAuthenticationTls-reference[TLS mechanism], as shown here, using xref:type-KafkaClientAuthenticationOAuth-reference[OAuth bearer tokens], or a SASL-based xref:type-KafkaClientAuthenticationScramSha512-reference[SCRAM-SHA-512] or xref:type-KafkaClientAuthenticationPlain-reference[PLAIN] mechanism.
<7> xref:con-common-configuration-bootstrap-reference[Bootstrap server] for connection to the source Kafka cluster.
<8> xref:con-common-configuration-trusted-certificates-reference[TLS encryption] with key names under which TLS certificates are stored in X.509 format for the source Kafka cluster. If certificates are stored in the same secret, it can be listed multiple times.
<9> xref:type-KafkaMirrorMaker2ClusterSpec-reference[Cluster alias] for the target Kafka cluster.
<10> Authentication for the target Kafka cluster is configured in the same way as for the source Kafka cluster.
<11> xref:con-common-configuration-bootstrap-reference[Bootstrap server] for connection to the target Kafka cluster.
<12> xref:property-kafka-connect-config-reference[Kafka Connect configuration].
Standard Apache Kafka configuration may be provided, restricted to those properties not managed directly by Strimzi.
<13> xref:con-common-configuration-ssl-reference[SSL properties] for external listeners to run with a specific _cipher suite_ for a TLS version.
<14> xref:type-KafkaMirrorMaker2ClusterSpec-reference[Hostname verification is enabled] by setting to `HTTPS`. An empty string disables the verification.
<15> TLS encryption for the target Kafka cluster is configured in the same way as for the source Kafka cluster.
<16> xref:type-KafkaMirrorMaker2MirrorSpec-reference[MirrorMaker 2.0 connectors].
<17> xref:type-KafkaMirrorMaker2MirrorSpec-reference[Cluster alias] for the source cluster used by the MirrorMaker 2.0 connectors.
<18> xref:type-KafkaMirrorMaker2MirrorSpec-reference[Cluster alias] for the target cluster used by the MirrorMaker 2.0 connectors.
<19> xref:type-KafkaMirrorMaker2ConnectorSpec-reference[Configuration for the `MirrorSourceConnector`] that creates remote topics. The `config` overrides the default configuration options.
<20> Replication factor for mirrored topics created at the target cluster.
<21> Replication factor for the `MirrorSourceConnector` `offset-syncs` internal topic that maps the offsets of the source and target clusters.
<22> When xref:con-mirrormaker-acls-{context}[ACL rules synchronization] is enabled, ACLs are applied to synchronized topics. The default is `true`.
<23> Defines the separator used for the renaming of remote topics.
<24> Adds a policy that overrides the automatic renaming of remote topics. Instead of prepending the name with the name of the source cluster, the topic retains its original name. This optional setting is useful for active/passive backups and data migration.
<25> xref:type-KafkaMirrorMaker2ConnectorSpec-reference[Configuration for the `MirrorHeartbeatConnector`] that performs connectivity checks. The `config` overrides the default configuration options.
<26> Replication factor for the heartbeat topic created at the target cluster.
<27> xref:type-KafkaMirrorMaker2ConnectorSpec-reference[Configuration for the `MirrorCheckpointConnector`] that tracks offsets. The `config` overrides the default configuration options.
<28> Replication factor for the checkpoints topic created at the target cluster.
<29> Topic replication from the source cluster xref:type-KafkaMirrorMaker2MirrorSpec-reference[defined as regular expression patterns]. Here we request all topics.
<30> Consumer group replication from the source cluster xref:type-KafkaMirrorMaker2MirrorSpec-reference[defined as regular expression patterns]. Here we request three consumer groups by name.
You can use comma-separated lists.
<31> Requests for reservation of xref:con-common-configuration-resources-reference[supported resources], currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
<32> Specified xref:property-kafka-connect-logging-reference[Kafka Connect loggers and log levels] added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom ConfigMap must be placed under the `log4j.properties` or `log4j2.properties` key. For the Kafka Connect `log4j.rootLogger` logger, you can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
<33> xref:con-common-configuration-healthchecks-reference[Healthchecks] to know when to restart a container (liveness) and when a container can accept traffic (readiness).
<34> xref:con-common-configuration-jvm-reference[JVM configuration options] to optimize performance for the Virtual Machine (VM) running Kafka MirrorMaker.
<35> ADVANCED OPTION: xref:con-common-configuration-images-reference[Container image configuration], which is recommended only in special situations.
<36> xref:assembly-customizing-kubernetes-resources-str[Template customization]. Here a pod is scheduled with anti-affinity, so the pod is not scheduled on nodes with the same hostname.
<37> Environment variables are also xref:ref-tracing-environment-variables-str[set for distributed tracing using Jaeger].
<38> xref:assembly-distributed-tracing-str[Distributed tracing is enabled for Jaeger].
<39> xref:type-ExternalConfiguration-reference[External configuration] for a Kubernetes Secret mounted to Kafka MirrorMaker as an environment variable.

. Create or update the resource:
+
[source,shell,subs=+quotes]
kubectl apply -f _<your-file>_
