我们使用Kafka Mirror Maker Version 1来镜像Kafka集群之间的数据。我知道MM 1已经过时了，但它是一个可靠的软件包，完全满足我们的需要。我们使用Kafka安装，它独立于我们存储数据的集群（目前运行的是Kafka Version 2.6）。
我们对“MirrorMaker-Kafka”使用了Kafka 2.7.x，最近将其更新为3.3.1。从那时起，我们在MM日志中有许多以下消息：
2022-12-01 15:07:45,368 INFO Metadata - [Producer clientId=*****] Resetting the last seen epoch of partition MyTopic-5 to 87 since the associated topicId changed from null to c59OzubzRAO-yhA72TSFEw
2022-12-01 15:12:45,373 INFO Metadata - [Producer clientId=*****] Resetting the last seen epoch of partition MyTopic-5 to 87 since the associated topicId changed from null to c59OzubzRAO-yhA72TSFEw
2022-12-01 15:22:45,388 INFO Metadata - [Producer clientId=*****] Resetting the last seen epoch of partition MyTopic-5 to 87 since the associated topicId changed from null to c59OzubzRAO-yhA72TSFEw
2022-12-01 15:37:45,394 INFO Metadata - [Producer clientId=*****] Resetting the last seen epoch of partition MyTopic-5 to 87 since the associated topicId changed from null to c59OzubzRAO-yhA72TSFEw
2022-12-01 15:42:45,398 INFO Metadata - [Producer clientId=*****] Resetting the last seen epoch of partition MyTopic-5 to 87 since the associated topicId changed from null to c59OzubzRAO-yhA72TSFEw正如您所看到的，该消息每隔5分钟重复一次。我们镜像了数百个分区，并为许多（可能是所有）分区记录了该消息。
正如我所发现的，该消息是在this commit的KAFKA-12257修复中引入的。
不幸的是，我不清楚这条信息的含义。在一定的时间间隔内不断重复也让我感到疑惑。可能我在我的（生产者）配置中仍然有弱点。
如果有人能解释这个现象，并知道我可以采取什么措施来改善它，我会很高兴。
1条答案
按热度按时间5lhxktic1#
您看到的消息与Kafka-12257修复程序相关，该修复程序用于解决生成器客户端无法正确跟踪主题分区的时期的问题。具体而言，该修复程序确保生成器客户端能够通过将唯一标识符（“topicId”）与分区的时期相关联来跟踪分区的时期。
在您的示例中，每5分钟记录一次该消息，因为生成器客户端正在将特定分区（MyTopic-5）的最后一次看到的epoch重置为87，因为关联的topicId从null更改为c59 OzubzRAO-yhA 72 TSFEw。
要确保生成器能够正确跟踪分区的纪元，应检查生成器配置并确保正确设置“topicId”。此外，还应确保生成器客户机配置为正确处理分区重新分配事件，因为这可能会导致topicId更改。
最后，如果您仍然遇到生产者客户端无法正确跟踪分区纪元的问题，您可能需要考虑升级到Kafka Mirror Maker的更新版本，因为MM 1现在已被弃用。