About KafkaMirrorMaker2

[chxliii]

I want to know, when using KafkaMirrorMaker2, its principle should be to use MirrorSourceConnector for data synchronization. Then must the brokers address of the target cluster of the newly created mirrorSourceConnector be the same as the kafka cluster that stores the kafka connect metadata? Because I saw in examples/mirror-maker/kafka-mirror-maker-2.yaml that spec.connectCluster and spec.mirrors.targetCluster are the same, does this mean that if I synchronize from kafka cluster A to kafka cluster C, where kafka connect metadata is stored in kafka cluster B, such a configuration cannot be implemented. It must be ensured that kafka cluster B and kafka cluster C are the same.

[kyguy]

To make sure I understand the question, you are asking that if you have 3 Strimzi-managed Kafka clusters:

• cluster-a
• cluster-b
• cluster-c

If it is possible for cluster-b to host KafkaMirrorMaker2 and synchronize the data between cluster-a as the source cluster and cluster-c as the target cluster. Did I interpret your question correctly?

[chxliii]

Yes, you are right. cluster b stores the metadata for mirrormaker2(because of its using kafka connect, kafka connect needs a kafka cluster to store the offset, task status info.)
cluster-a ——> source kafka cluster
cluster-c ——> target kafka cluster

My question is can the target cluster c be different from cluster b? I seem to see that the best recommendation is that cluster b and cluster c should be the same. But I would like cluster b to be different from cluster c. Cluster b is only used just as mirrormaker2 to store metadata, the target cluster is additional other clusters which are not the same!

[kyguy]

TBH I am not sure; however, @mimaison may know.

[mimaison]

It's technically possible to have Connect use cluster B and run the MirrorMaker connectors to mirror data from A to C. However it's not a recommended setup, especially if you're not very familiar with Connect, as the configuration is a bit tricky. Keep in mind that this comes with a number of gotchas. For example if cluster B has an issue, it compromises your mirroring while A and C are running fine. Also it's recommended to run Connect near the target cluster, by connecting it to another cluster you have more potential issues. So I'd be sure you have a very good reason before setting this up.

If you really want to do so, you need to override the Connect internal client connection configurations in your connector's configuration to point to them to cluster B. To do so you need to use the consumer.override., producer.override. and admin.override. prefixes to set the necessary connection configurations (at least bootstrap.servers, plus any SSL, SASL configurations as needed).

Client overrides are briefly covered in https://kafka.apache.org/documentation/#connect_running

[scholzj]

However, this is not supported as part of the Strimzi KafkaMIrrroMaker2 resource!

[chxliii]

Thanks! I got it.

[JaeHyeokLee]

@mimaison @chxliii I have same question of this discussion. can you explain more detail?

1. can you explain more detail about it's recommended to run Connect near the target cluster ? I wonder why connect cluster at target cluster is better than connect cluster at source cluster.

2. I try to mirror data from cluster a to cluster b (cluster a -> cluster b), it is possible to deploy connect both cluster A and cluster B.

• cluster A -> MirrorSourceConnector at connect of cluster A -> cluster B
• cluster A -> MirrorSourceConnector at connect of cluster B -> cluster B

First I tried cluster A -> MirrorSourceConnector at connect of cluster A -> cluster B, but it doesn't work well. It copied data cluster A -> cluster A (I expected bootstrap servers of producer created by MirrorSourceConnector cluster B and bootstrap servers of consumer created by MirrorSourceConnector is cluster A. But both bootstrap servers of Consumer and Producer are cluster A...)

I expected consumer bootstrap servers and producer bootstrap servers are automatically overridden by MirrorSourceConnector. is it impossible to override bootstrap servers by MirrorSourceConnector?
And should I add consumer.override.bootstrap.servers and producer.override.bootstrap.servers to locate connect cluster at source cluster (cluster A)?

[mimaison]

@JaeHyeokLee It looks like a completely different question to me, your scenario does not have 3 clusters. I'll reply briefly but please avoid adding different questions to existing threads. If you have another question, start a new thread.

1. This is described in the MirrorMaker documentation: https://kafka.apache.org/documentation/#georeplication-best-practice

To minimize latency ("producer lag"), it is recommended to locate MirrorMaker processes as close as possible to their target clusters, i.e., the clusters that it produces data to. That's because Kafka producers typically struggle more with unreliable or high-latency network connections than Kafka consumers.

2. Mirroring data from cluster A to B is the most basic use case of MirrorMaker. That is known to work well. As per 1. the recommendation is to put Connect next to the target cluster, but it also works if it's near the source cluster. Without any details I can't guess what's wrong with your configuration. I suggest checking both the Apache Kafka docs (https://kafka.apache.org/documentation/#georeplication) and the Strimzi docs (https://strimzi.io/docs/operators/latest/deploying#kafka-mirror-maker-str) that cover how to set MirrorMaker up.

[chxliii]

In fact, after verification, I found that even if the target cluster of target.cluster.* is specified as an additional third-party cluster (a cluster different from the Kafka cluster that stores the Kafka Connect metadata), it will not take effect. It seems that the Kafka cluster where the target is written and the cluster that stores the Kafka Connect metadata must be the same