EC2上的卡夫卡集群面临“分区缩小的zkVersion”和“缓存的zkVersion []不等于动物园管理员，跳过更新ISR”
我有一个基于t2.medium实例的3节点kafka集群。动物园管理员和代理部署在同一个ec2实例中。ec2实例分布在区域内的3个diff区域中。设置如下：
- 动物园管理员有以下内存设置：
export KAFKA_HEAP_OPTS="-Xmx512M -Xms512M" - 代理具有以下内存设置：
export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G" Kafka Version - 0.10.1.1，正式与spring-boot 1.5.10兼容- 与卡夫卡捆绑在一起的动物园管理员正被用来安装。
流量模式:流量不高(可能是4 is /秒)，但是大量的消息(500 is/秒)可以在短时间内到达2-3分钟。
所面临的问题: 1.代理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)
这使得集群不稳定，在执行所有代理(有时也是动物园管理员)的滚动重新启动之前，集群永远不会自己恢复。
当从AWS EC2控制台中可用的Metrics中检查nw时，除了流量激增之外，没有明显的nw问题。当问题开始时，从nw的角度看，日志中也没有任何内容。在开始报告时，似乎有GC运行，然后继续报告kafkaServer-GC.log，直到执行整个集群的滚动重新启动。
- 处理这种情况的正确实例类型应该是什么？理想的内存设置是什么？在这方面是否还有其他可以纠正的配置？
- 有办法找出有问题的节点吗？
- 我们如何决定仅仅重新启动代理是否有帮助，还是所有代理都需要重新启动？
- 如何确定动物园管理员是否也需要重新启动，以及/或所有动物园管理员实例也需要重新启动？有没有办法用四个字母的词与
zookeeper-shell.sh捆绑在一起卡夫卡？ - 怎样才能采取积极主动的监测措施来及早发现这一情况？
这里非常需要一些指导，不用说，我们非常感谢它！
回答 1
Stack Overflow用户
发布于 2018-06-16 10:28:26
可能是您的流量选择导致了这个问题，并且您的代理丢失了接收器状态。您需要微调一些参数，其中一些参数在正式文档中引用：
与大多数分布式系统一样，自动处理故障需要对节点“活着”的含义有一个精确的定义。对于Kafka来说，节点活性有两个条件
- 节点必须能够使用ZooKeeper (通过动物园管理员的心跳机制)维护其会话。
- 如果它是一个奴隶，它必须复制发生在领导者身上的文字，而不是落在“太远”的后面。
我们将满足这两个条件的节点称为“同步”节点，以避免“活着”或“失败”的模糊性。领导者跟踪一组“同步”节点。如果跟随者死亡、卡住或落后，领导者将从同步副本列表中删除它。“落后多远”的定义由replica.lag.max.messages配置控制，而卡住副本的定义则由replica.lag.time.max.ms配置控制。
还可以尝试使用代理堆内存(请参阅这)。
关于监视，通过JMX，您可以查看许多指标，其中特别是：
ISR收缩率& ISR膨胀率
https://stackoverflow.com/questions/50885752
复制相似问题
腾讯云开发者
