因此,我们启动了许多Kafka Streams应用程序,而没有意识到默认的复制因子为1。
我们已经修改了代码(例如What should be the replication factor of changelog/repartition topics)
但是,我认为这对已经部署的应用程序或更改已经创建的内部主题没有帮助。
例如,我使用kafkacat
列出了几个主题(基于application.id
前缀,并且都具有一个副本)
很明显,当代理开始出现问题时(此处为broker.id
11或21),应用程序无法正常运行。
topic "appid-KTABLE-SUPPRESS-STATE-STORE-0000000013-changelog" with 1 partitions:
partition 0, leader 11, replicas: 11, isrs: 11
--
topic "appid-KSTREAM-AGGREGATE-STATE-STORE-0000000019-changelog" with 1 partitions:
partition 0, leader 21, replicas: 21, isrs: 21
--
topic "appid-KSTREAM-AGGREGATE-STATE-STORE-0000000009-changelog" with 1 partitions:
partition 0, leader 11, replicas: 11, isrs: 11
--
topic "appid-KSTREAM-AGGREGATE-STATE-STORE-0000000007-changelog" with 1 partitions:
partition 0, leader 21, replicas: 21, isrs: 21
我了解如何增加复制因子(例如How to change the number of replicas of a Kafka topic?),但是我的问题
这些数字是否具有除Kafka Streams的处理器顺序以外的特定含义?
我真的应该增加其中几个主题的复制因子(假设我手动进行复制,并且必须对多个集群进行复制)?
此外:由于应用程序如何写入下游系统,因此重置流应用程序以清理内部主题似乎不是一个好选择。
答案 0 :(得分:1)
appid-KTABLE-SUPPRESS-STATE-STORE-0000000013-changelog
中的这些数字表示拓扑app-id
拓扑中的处理器节点ID。拓扑由许多处理器节点构建,并且每个节点都分配有唯一的ID。
除非您通过添加或删除一些处理器节点来更改拓扑,否则它将对重新分区/更改日志主题使用相同的名称和编号。在这种情况下,您必须重置应用程序ID并重新启动所有实例。更改复制因子的数量不会影响数字。
但是我建议重置应用程序以清理旧的内部主题,并使用更新的复制因子配置重新运行该应用程序,因为要在代理节点之间分布副本,您将必须像下面那样运行重新分配:< / p>
bin / kafka-reassign-partitions.sh --zookeeper本地主机:2181 --reassignment-json-file增加复制因子.json --execute
您可以在此处找到更多详细信息: https://kafka.apache.org/documentation/#basic_ops_increase_replication_factor