Question

我们一直在尝试在AWS Linux机器上建立生产级别的Kafka集群，直到现在我们仍然没有成功。

Kafka版本： 2.1.0

机器：

5 r5.xlarge machines for 5 Kafka brokers.
3 t2.medium zookeeper nodes
1 t2.medium node for schema-registry and related tools. (a Single instance of each)
1 m5.xlarge machine for Debezium.

默认代理配置：

num.partitions=15
min.insync.replicas=1
group.max.session.timeout.ms=2000000 
log.cleanup.policy=compact
default.replication.factor=3
zookeeper.session.timeout.ms=30000

我们的问题主要与海量数据有关。我们正在尝试使用debezium在kafka主题中转移现有表。这些表中的许多表都非常庞大，超过5000万行。

到目前为止，我们已经尝试了很多方法，但是每次群集故障都有一个或多个原因。

ERROR计划任务'isr-expiration'（kafka.utils.KafkaScheduler）中未捕获的异常 org.apache.zookeeper.KeeperException $ SessionExpiredException：KeeperErrorCode = / brokers / topics / __ consumer_offsets / partitions / 0 / state的会话已过期在org.apache.zookeeper.KeeperException.create（KeeperException.java:130）在org.apache.zookeeper.KeeperException.create（KeeperException.java:54）..

错误2：

] INFO [Partition xxx.public.driver_operation-14 broker = 3]缓存的zkVersion [21]与zookeeper中的不相等，请跳过更新ISR（kafka.cluster.Partition） [2018-12-12 14：07：26,551]信息[Partition xxx.public.hub-14 broker = 3]将ISR从1,3缩减到3（kafka.cluster.Partition） [2018-12-12 14：07：26,556]信息[Partition xxx.public.hub-14 broker = 3]缓存的zkVersion [3]不等于zookeeper中的zkVersion，请跳过更新ISR（kafka.cluster.Partition） [2018-12-12 14：07：26,556]信息[分区xxx.public.field_data_12_2018-7 broker = 3] ISR从1,3缩减到3（kafka.cluster.Partition）

错误3：

isolationLevel = READ_UNCOMMITTED，toForget =，元数据=（sessionId = 888665879，epoch = INITIAL））（kafka.server.ReplicaFetcherThread） java.io.IOException：在读取响应之前已断开与3的连接在org.apache.kafka.clients.NetworkClientUtils.sendAndReceive（NetworkClientUtils.java:97）

更多错误：

经纪人之间经常断开连接，这可能是原因在不自动恢复的情况下不停地缩小和扩展ISR。
架构注册表超时。我不知道架构注册表如何受到影响。我在该服务器上看不到太多负载。我想念什么吗？我应该为架构注册表的多个实例使用负载均衡器作为故障转移吗？。主题__schemas中只有28条消息。确切的错误消息是RestClientException：注册操作超时。错误代码：50002
有时消息传输速率超过每秒100000条消息，有时下降到2000条消息/秒？邮件大小可能会导致这种情况？

为了解决上述一些问题，我们增加了经纪人数量，并增加了zookeeper.session.timeout.ms = 30000，但我不确定它是否真的解决了我们的问题，如果解决了，怎么办？

我有几个问题：

我们的集群足以应付这么多数据吗？
有什么明显的失踪吗？
如何在进入生产级别之前对设置进行负载测试？
是什么导致代理与架构注册表之间的会话超时。
处理架构注册表问题的最佳方法。

我们的经纪人之一上的网络负载。

随时询问更多信息。

Answer 1

请为您的群集使用Confluent的最新正式版本。

实际上，您可以通过增加主题的分区数量并增加tasks.max（当然在接收器连接器中）来使情况更好连接器中的1倍以上即可同时工作并更快地工作。

请增加Kafka-Connect主题的数量，并使用 Kafka-Connect分布式模式来增加Kafka-connect集群的高可用性。您可以通过在 Kafka-Connect 和 Schema-Registry 配置中设置复制因子的数量来实现，例如：

config.storage.replication.factor=2
status.storage.replication.factor=2
offset.storage.replication.factor=2

请为大型表格将topic compression设置为snappy。它将提高主题的吞吐量，这有助于 Debezium 连接器更快地工作并且不使用 JSON Converter ，建议使用 Avro Converter >！

还请对您的 Schema Registry

使用负载均衡器

要测试群集，您可以使用database.whitelist创建仅包含一个表（我的意思是大表！）的连接器，并将snapshot.mode设置为initial

关于模式注册表！架构注册用户 Kafka 和 Zookeeper 都设置了以下配置：

bootstrap.servers
kafkastore.connection.url

这就是您导致shema-registry集群停机的原因

Apache Kafka生产集群设置问题

1 个答案: