我在更改与kafka相关的某些属性并重新启动群集时面临以下问题。
In kafka Consumer, there were 5 consumer jobs are running .
如果我们进行了一些重要的属性更改，并且在重新启动群集时，部分/所有现有的消费者作业都无法启动。
Ideally all the consumer jobs should start ,
因为它将从以下系统主题中获取元数据信息。
config.storage.topic
offset.storage.topic
status.storage.topic
答案 0 :(得分：5)
首先，有点背景知识。 Kafka将其所有数据存储在topics中，但这些主题（或者更确切地说是构成主题的分区）是仅附加日志，除非完成某些操作，否则这些日志将永远增长。为了防止这种情况，Kafka能够以两种方式清理主题：保留和压缩。配置为使用 保留 的主题将保留数据一段可配置的时间：代理可以自由删除任何早于此的日志消息。配置为使用compaction的主题要求每条消息都有一个密钥，并且代理将始终为每个不同的密钥保留最后一条已知消息。当每个消息（即，键/值对）表示密钥的最后已知状态时，压缩是非常方便的;因为消费者正在阅读主题以获得每个密钥的最后已知状态，所以如果删除旧状态，它们最终会更快地到达最后状态。
经纪人将用于某个主题的清理策略取决于几个方面。默认情况下，隐式或显式创建的每个主题都将使用保留，但您可以通过以下几种方式进行更改：
log.cleanup.policy代理设置，仅影响该点之后创建的主题;或cleanup.policy主题特定设置
现在，Kafka Connect使用多个内部主题来存储连接器配置，偏移和状态信息。这些内部主题必须为compacted topics，以便（至少）每个连接器的最后配置，偏移和状态始终可用。由于Kafka Connect从不使用较旧的配置，偏移和状态，因此代理从内部主题中删除它们实际上是件好事。
在Kafka 0.11.0.0之前，recommended process将使用正确的主题特定设置手动创建这些内部主题。您可以依赖代理自动创建它们，但这有几个原因是有问题的，其中最重要的是三个内部主题应该有不同数量的分区。
如果这些内部主题不是压缩，则会在保留期过后清除并删除配置，偏移和状态信息。默认情况下，此保留期为24小时！这意味着如果在部署/更新连接器配置后超过24小时重新启动Kafka Connect，则该连接器的配置可能已被清除，并且看起来好像连接器配置从未存在过。
因此，如果您没有正确创建这些内部主题，只需使用topic admin tool将主题设置更新为described in the documentation。
BTW，没有正确创建这些内部主题是一个非常常见的问题，以至于Kafka Connect 0.11.0.0将能够使用正确的设置自动创建这些内部主题，而不依赖于代理自动创建主题。在0.11.0中，您仍然需要依赖手动创建或代理自动创建源连接器写入的主题。这并不理想，因此有一个proposal可以更改Kafka Connect以自动创建源连接器的主题，同时让源连接器控制设置。希望这种改进使其成为0.11.1.0，以便Kafka Connect更易于使用。