如何解决Kafka log.segment.bytes 与 log.retention.hours
我正在阅读《Kafka:权威指南》第一版一书,以了解代理何时删除日志段。
根据我所理解的文本,一个段在关闭之前不会被删除。只有当段达到 log.segment.bytes 大小时才能关闭段(考虑到 log.segment.ms 未设置)。一旦一个段符合删除条件,log.retention.ms 策略将适用于最终决定何时删除该段。
然而,这似乎与我在我们的生产集群(Kafka ver 2.5)中看到的行为相矛盾。
只要满足 log.retention.ms,日志段就会被删除,即使段大小小于 log.segment.bytes。
[2020-12-24 15:51:17,808] INFO [日志分区=Topic-2, dir=/Folder/Kafka_data/kafka] 找到可删除的段 偏移 [165828] 由于保留时间 604800000 毫秒违规 (kafka.log.Log)
[2020-12-24 15:51:17,808] INFO [日志分区=Topic-2, dir=/Folder/Kafka_data/kafka] 调度要删除的段 列表(LogSegment(baSEOffset=165828,size=895454171,lastModifiedTime=1608220234000,最大时间=1608220234478)) (kafka.log.Log)
大小仍然小于 1GB,但该段已被删除。
这本书在发布新闻时提到 Kafka 版本是 0.9.0.1 。在后来的 Kafka 版本中,这个设置也发生了变化。 (我在 Kafka 文档中找不到任何关于此更改的具体提及)。以下是书中的摘录。
解决方法
您观察到的是预期的行为,它也是 discussed here。简而言之,如果您有一个尚未满的活动段,并且 retention.ms
已经过去,那么即使未满,它也会被关闭并变成“旧日志段”。
设置:log.retention.ms
和 log.retention.bytes
Kafka broker 将消息保留多长时间(实际上,“日志段”)的最常见配置是按时间(以毫秒为单位),并使用 log.retention.ms
参数指定(默认为 1 周)。如果设置为 -1,则不应用时间限制。
另一种过期方法是基于保留的消息的总字节数。该值是使用 log.retention.bytes
参数设置的,它适用于每个分区。它的默认值是 -1,允许无限保留。这意味着如果您有一个有 8 个分区的主题,并且 log.retention.bytes 设置为 1 GB,则该主题保留的数据量最多为 8 GB。如果您同时指定了 log.retention.bytes
和 log.retention.ms
,则在满足任一条件时可能会删除消息。
设置:log.segment.bytes
和 log.segment.ms
当向 Kafka 代理生成消息时,它们会附加到分区的当前日志段。一旦日志段达到 log.segment.bytes
参数指定的大小(默认为 1 GB),日志段将关闭并打开一个新的。只有在日志段关闭后,才可以考虑到期(通过 log.retention.ms
或 log.retention.bytes
)。
控制日志段何时关闭的另一种方法是使用 log.segment.ms
参数,该参数指定应在多长时间后关闭日志段。 Kafka 将在达到大小限制或达到时间限制时关闭日志段,以先到者为准。
较小的日志段大小意味着必须更频繁地关闭和分配文件,这会降低磁盘写入的整体效率。如果主题的生成率较低,则调整日志段的大小可能很重要。例如,如果某个主题每天仅接收 100 兆字节的消息,并且 log.segment.bytes
设置为默认值,则填充一个段需要 10 天。由于消息在日志段关闭之前无法过期,如果 log.retention.ms
设置为 1 周,它们实际上将最多保留 17 天的消息,直到关闭段过期。这是因为一旦日志段被当前 10 天的消息关闭,根据时间策略,该日志段必须在其过期前 7 天保留。
希望这变得更清楚。
segment.ms => 段文件的最大年龄(从 创作)
retention.ms => 段中任何消息的最大年龄(即 关闭)超过此段有资格删除(如果删除 政策已设置)
因此,如果该段是“活动段”,那么它可以基于 segment.ms(或 segment.bytes)而不是保留.ms 进行翻转。保留仅在关闭(非活动)细分市场上发挥作用。
所以从书中引用的行为是正确的。但是,您认为该段处于活动状态并且 INFO 日志指定该段已设置为删除。 这不会发生在活动段上(假设没有错误)。该段必须在任何保留之前关闭(未激活)。* 属性才能生效。
见this。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。