• kafka问题集(二):__consumer_offsets topic的分区中有一个分区数据很多,多达1T


    仅个人实践中所遇到的问题,若有不对的,欢迎交流!


    一、场景描述

      kafka集群中有几台突然挂了,后台日志显示设备空间满了,消息无法写入__consumer_offsets topic的分区中了。查看kafka数据目录下各个文件的大小,发现__consumer_offsets topic分区中有一个分区__consumer_offsets-5数据很多,多达1T,而其他分区只有4KB,相差巨大。且__consumer_offsets-5中保留了一年多的数据。什么情况?不应该自动清除吗?

    二、问题分析

      1)__consumer_offsets分区中数据量相差这么大?

        __consumer_offsets topic的分区中存放的是consumer的offset等信息,其存放机制是用消费组id的hash值对分区数取模得到的。而我们只有一个消费组,所以会导致__consumer_offsets topic中的数据都写入一个分区。

      2)__consumer_offsets-5保留的一年多数据,为什么没有被清理?不是已经设置了log.retention.hours、log.retention.bytes这些参数了吗?

        首先说一点,__consumer_offsets的cleanup.policy策略是compact,而我们新建topic的清理策略默认是deleted,前者可以使用--describe 加上--topic  __consumer_offsets 可以看到,而后者可以在server.properties上可以看到。参数log.cleaner.enable参数对清理策略为compact起作用,且不是通过压缩(compact)文件达到减少数据的目的,通过测试,我们发现当文件属性不满足log.retention.hours、log.retention.bytes其中任何一项时,.log的数据文件文件就会被删除。当然也不是直接删除,是先将文件标记为-deleted,然后被清除。因为测试的时候被标记为-deleted后,再次执行ll命令时,文件已经被删除了,不知道删除时间间隔是否和参数log.retention.check.interval.ms有关,若有大佬知道欢迎留言分享。

        知道文件清理规则后,检查log.cleaner.enable设置,为false,故将其改为true即可。

    三、测试过程

      修改参数log.segment.bytes的大小为1M,使得__consumer_offsets topic的分区中.log文件大小保留为1M;为了尽快确定log.cleaner.enable改为true是否会减小__consumer_offsets topic的分区中数据量的大小,需要修改触发删除的阈值。为减小阈值,修改log.retention.bytes为2M。但是在实际测试中我们发现当__consumer_offsets topic的分区中的.log大小为50M的时候还是没有触发删除。使用以下命令查看__consumer_offsets topic时发现,其默认的configure :segment.bytes大小为104857600,即为100M。

    1 kafka-topics --decribe --zookeeper localhost:2181/kafka --topic __consumer_offsets

      通过查看kafka官网上有关segment bytes配置说明,发现删除时是以一个文件执行的,这个参数控制着文件大小。原文如下:

    This configuration controls the segment file size for the log. Retention and cleaning is always done a file at a time so a larger segment size means fewer files but less granular control over retention.

      使用命令将这个segment.bytes改为10M,发现__consumer_offsets-5分区的数据很快就变为400+KB了。修改命令如下:

    1 kafka-topics --zookeeper localhost:2181/kafka --alter --topic __consumer_offsets --config segment.bytes=10485760

    四、应急策略

      当时因为是生产环境出现问题,来不及分析,要尽快将生产恢复正常,只能临时将日志等信息保留下来,以待后续分析。上述的分析还是自己后来查找资料知道的。当时采取的策略如下:

      停止程序;增加磁盘;删除topic;新建topic;启动程序;

      耗时近一个半小时,消费正常。这个步骤肯定是不行的,但是当时不是很懂,所以采取了临时的策略,欢迎大佬分享自己遇到这种问题时采取的措施!    

    五、参考文献

      1)https://support.huawei.com/enterprise/zh/knowledge/KB1000676043/

      2)https://www.sohu.com/a/136881236_487514

        

  • 相关阅读:
    js或css文件后面的参数是什么意思?
    查看mysql语句运行时间的2种方法
    lumia手机wp系统应用列表如何设置按照拼音
    每一个你不满意的现在,都有一个你没有努力的曾经。
    一行代码实现防盗链!
    请写一个php函数,可以接受任意数量的参数
    ajax处理缓冲问题
    Textarea自动适用高度且无滚动条解决方案
    PHP Warning exec() has been disabled for security reasons怎么办
    各种字符编码方式详解及由来(ANSI,UNICODE,UTF-8,GB2312,GBK)
  • 原文地址:https://www.cnblogs.com/love-yh/p/10347186.html
Copyright © 2020-2023  润新知