[
https://issues.apache.org/jira/browse/KAFKA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232354#comment-17232354
]
Ning Zhang commented on KAFKA-10719:
------------------------------------
The potential config inconsistence of MM2 may be rooted at how Kafka Connect
saves the config, simply because MM2 is built on top of Kafka Connect.
Typically Kafka Connect put config in a special kafka topic. By reading the
description section of
[https://github.com/a0x8o/kafka/blob/master/connect/runtime/src/main/java/org/apache/kafka/connect/storage/KafkaConfigBackingStore.java]
In rare cases, there is a chance of seeing inconsistent config across
different tasks.
> MirrorMaker2 fails to update its runtime configuration
> ------------------------------------------------------
>
> Key: KAFKA-10719
> URL: https://issues.apache.org/jira/browse/KAFKA-10719
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 2.6.0
> Reporter: Peter Sinoros-Szabo
> Priority: Major
>
> I was running successfully the MM2 cluster with the following configuration,
> I simplified it a little: {code:java} clusters = main, backup
> main.bootstrap.servers = kafkaA:9202,kafkaB:9092,kafkaB:9092
> backup.bootstrap.servers = backupA:9092,backupB:9092,backupC:9092
> main->backup.enabled = true main->backup.topics = .*{code} I wanted to change
> the bootstrap.address list of the destination cluster to a different list
> that is pointing to the *same* cluster, just a different listener with a
> different routing. So I changed it to: {code:java} backup.bootstrap.servers =
> backupSecA:1234,backupSecB:1234,backupSecC:1234{code} I did a rolling restart
> on the MM2 nodes and say that some tasks were still using the old bootstrap
> addresses, some of them were using the new one. I don't have the logs, so
> unfortunately I don't know which one picked up the good values and which
> didn't. I even stopped the cluster completely, but it didn't help. Ryanne
> adviced to delete the mm2-config and mm2-status topics, so I did delete those
> on the destination cluster, that solved this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
