我们使用 Kafka Mirror Maker Version 1 在 Kafka 集群之间镜像数据。我知道 MM1 已被弃用，但它是一款可靠的软件，完全可以满足我们的需求。我们在专用的 Kafka 安装中使用它，该安装独立于我们存储数据的集群（目前正在运行 Kafka 2.6 版本）。
我们使用 Kafka 2.7.x 作为“MirrorMaker-Kafka”，最近将其更新到 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 分钟重复一次。我们镜像了数百个分区，并记录了许多（也许是所有）分区的消息。
据我发现，该消息是在 此提交中的 KAFKA-12257 修复中引入的。
不幸的是，我不清楚该消息的含义。以一定的间隔不断重复也让我感到好奇。可能我的（生产者）配置仍然存在弱点。
如果有人能解释这个现象并知道我可以采取什么措施来改善它，我会非常高兴。
您看到的消息与 KAFKA-12257 修复相关，该修复是为了解决生产者客户端无法正确跟踪主题分区的纪元的问题而实现的。具体来说，该修复确保生产者客户端能够通过将唯一标识符（“topicId”）与其关联来跟踪分区的纪元。
在您的情况下，每 5 分钟记录一次消息，因为生产者客户端将特定分区 (MyTopic-5) 的最后一次看到的纪元重置为 87，因为关联的 topicId 从 null 更改为 c59OzubzRAO-yhA72TSFEw。
为了确保生产者能够正确跟踪分区的纪元，您应该检查生产者配置并确保“topicId”设置正确。此外，您还应该确保您的生产者客户端配置为正确处理分区重新分配事件，因为这可能会导致 topicId 发生更改。
最后，如果您仍然遇到生产者客户端无法正确跟踪分区纪元的问题，您可能需要考虑升级到 Kafka Mirror Maker 的新版本，因为 MM1 现已弃用。
可能是您正在使用的消费者组 ID 无权访问您的主题。请检查 kafka 日志。
根据https://forum.confluence.io/t/resetting-the-last-seen-epoch-of-partition/6740/2：
When a client first try to consume/produce from/to a topic, it will initialise an object in memory to track the topic metadata, and upon the first metadata response received from the kafka cluster.It will update its state from the default null to the actual topic ID.这听起来好像这个错误可以被安全地忽略，只要它是从 null 改变的，而不是其他值，在这种情况下我会更详细地查看它。