ec2上的kafka群集面临“正在缩小分区的isr”和“缓存的zkversion[]不等于zookeeper中的版本,跳过更新isr”

im9ewurl  于 2021-06-08  发布在  Kafka
关注(0)|答案(1)|浏览(772)

我有一个3节点的Kafka集群 t2.medium 示例。zookeeper和broker部署在同一个ec2示例中。ec2示例分布在一个区域内的3个不同av区域。设置如下:
zookeeper具有以下内存设置: export KAFKA_HEAP_OPTS="-Xmx512M -Xms512M" 代理具有以下内存设置:
export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G" Kafka Version - 0.10.1.1 正式符合 spring-boot 1.5.10 与Kafka捆绑的zookeeper正在用于设置。
流量模式:流量不高(可能是4毫秒/秒),但是大量的消息(500毫秒/秒)可以在短时间内[2-3分钟]到达。
面临的问题:1。在broker server.log中报告以下内容
INFO Partition [topic1,0] on broker 0: Shrinking ISR for partition [topic1,0] from 0,1,2 to 0 (kafka.cluster.Partition) INFO Partition [topic1,0] on broker 0: Cached zkVersion [8] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition) 这使得集群不稳定,直到执行所有代理的滚动重新启动(有时也是zookeers),集群才自行恢复。
当从aws ec2控制台中可用的度量进行检查时,没有明显的nw问题,除了流量峰值。当问题开始时,从nw的Angular 来看,日志中也没有任何内容。当它开始报告,然后继续报告时,似乎有一个gc运行 kafkaServer-GC.log ,直到执行整个集群的滚动重启。
处理这种情况的正确示例类型应该是什么?理想的内存设置是什么?在这方面是否有其他配置可以纠正?
有没有办法找出有问题的节点?
我们如何决定是单独重新启动代理有帮助,还是所有代理也需要重新启动?
我们如何决定是否也需要重新启动zookeeper,和/或所有zookeeper示例也需要重新启动?有没有办法把四个字母的单词和 zookeeper-shell.sh 和Kafka捆绑在一起?
什么是主动监测步骤,可以及早发现这种情况?
这里非常需要一些指导,更不用说非常感谢!

mlnl4t2r

mlnl4t2r1#

可能是你的流量选择导致了这个问题,而你的代理在sink状态下丢失了。您需要微调一些参数,其中一些参数在官方文档中引用:
与大多数分布式系统一样,自动处理故障需要精确定义节点“活动”的含义。对于Kafka来说,节点的活跃度有两个条件
节点必须能够保持与zookeeper的会话(通过zookeeper的心跳机制)
如果它是一个奴隶,它必须复制发生在领导者身上的书写,而不是落在“太远”的后面
我们将满足这两个条件的节点称为“同步”,以避免“活动”或“失败”的模糊性。引线跟踪“同步”节点集。如果跟随者死亡、卡住或落后,领导者将从同步副本列表中删除该跟随者。“落后多远”的定义由replica.lag.max.messages配置控制,而“卡住的副本”的定义由replica.lag.time.max.ms配置控制。
还可以尝试使用代理堆内存(请参见此图)。
关于监控,通过jmx,您可以查看许多指标,尤其是:
isr收缩率和isr扩展率
裁判:https://kafka.apache.org/082/documentation/#ops

相关问题