Kafka удаляет сегменты еще до того, как достигнут размер сегмента

Я играю с Kafka на своем локальном компьютере, и я добавил следующую конфигурацию темы:

bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 config retention.ms=60000
bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 —config file.delete.delay.ms=40000
bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 --config segment.bytes=400000

Насколько я понимаю, сегмент будет удален, когда сегмент достигнет указанного выше размера сегмента (segment.bytes = 400000) ПЛЮС каждое отдельное сообщение в сегменте старше указанного выше срока хранения (retention.ms = 60000).

Я заметил, что сегмент всего из 35 байтов, который содержал только одно сообщение, был удален через минуту (может быть, немного больше).

Где я могу получить эту информацию? из сообщения Linkedin Engineer о том, как работает процесс удаления:

Удержание будет основано на сочетании настроек хранения и размера сегмента (в качестве примечания рекомендуется использовать log.retention.ms и log.segment.ms, а не конфигурацию часов. Это существует по устаревшим причинам, но конфиги ms более согласованные). Когда сообщения принимаются Kafka, они записываются в текущий открытый сегмент журнала для каждого раздела. Этот сегмент поворачивается при достижении предела log.segment.bytes или log.segment.ms. Как только это произойдет, сегмент журнала закрывается и открывается новый. Только после закрытия сегмента журнала его можно удалить с помощью настроек хранения. Как только сегмент журнала закрывается И либо все сообщения в сегменте старше, чем log.retention.ms, ИЛИ общий размер раздела превышает log.retention.bytes, сегмент журнала очищается.

Ссылка: Как работает удержание


apache-kafka
person Columb1a    schedule 08.12.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Вы упускаете из виду некоторые из цитируемых вами утверждений:

Этот сегмент поворачивается при достижении предела log.segment.bytes или log.segment.ms.

Это ясно говорит о том, что вращение может быть вызвано размером или временем. Это или, а не и.

Как только это произойдет, сегмент журнала закрывается. [...] После закрытия сегмента журнала И либо все сообщения в сегменте старше, чем log.retention.ms, ИЛИ общий размер раздела больше, чем log.retention.bytes, сегмент журнала очищается.

Таким образом, после того, как сегмент был закрыт вращением по времени, он может быть удален независимо от его размера.

person Matthias J. Sax    schedule 09.12.2016
comment
Погодите, я не уверен, что пропускаю интерпретацию заявлений. Давайте разберемся: в моем случае сегмент будет вращаться при достижении сегмента segment.bytes (segment.bytes = 400000). ТО, если все сообщения в сегменте, который был повернут, старше retention.ms = 60000, ТО удалите сегмент. - person Columb1a; 09.12.2016
comment
Фактически я только что проверил значение, относящееся к segment.ms. Он установлен на 604800000 (168 часов). Таким образом, мы можем даже отказаться от того, что для segment.ms установлено очень низкое значение (и с этим сбросом сегменты поворачиваются, потому что свойство segment.ms было достигнуто до свойства segment.bytes). - person Columb1a; 09.12.2016
comment
Сегмент также можно повернуть, если он не заполнен, но время его удерживания истекло. Таким образом, это неверно: в моем случае сегмент будет повернут при достижении сегмента segment.bytes (segment.bytes = 400000). В вашем случае сегмент поворачивается, потому что время удерживания проходит. Кроме того, время удерживания не связано с segment.ms - на самом деле сегмент .ms - это третья политика / триггер ротации в дополнение к размеру сегмента и времени удержания. - person Matthias J. Sax; 09.12.2016
comment
Я думаю, что и ты, и я думаем об одном и том же, но, возможно, я не очень хорошо это объясняю. Давайте посмотрим на определение retention.ms: эта конфигурация контролирует максимальное время, в течение которого мы будем хранить журнал, прежде чем мы отбросим старые сегменты журнала, чтобы освободить место, если мы используем политику хранения при удалении. Таким образом, retention.ms - это период хранения для отбрасывания старых сегментов. Я знаю, что retention.ms и segment.ms НЕ связаны. Я не смешиваю то и другое. - person Columb1a; 09.12.2016
comment
Я согласен с этим утверждением. Однако, если у вас есть текущий сегмент, который еще не заполнен, и время хранения прошло, сегмент будет закрыт и превратится в старый сегмент журнала, даже если он не заполнен. Таким образом, он будет удален. Возможно, документация недостаточно ясна, но вы наблюдаете такое поведение - так почему вы думаете, что мое объяснение неверно? - person Matthias J. Sax; 09.12.2016
comment
Правильно! это то, что я собирался прокомментировать. Таким образом, не существует такой вещи, как только те сегменты, которые были закрыты (те, которые достигли 400000 байт), могут быть кандидатами на удаление. Что-то не так в заявлении Туда Палино. - person Columb1a; 09.12.2016
comment
Я считаю это утверждение правильным. Вопрос в правильном порядке следования в утверждении. Если Тодд говорит, что кандидатами на удаление могут быть только те сегменты, которые были закрыты, он прав. ИМХО, ваша пропущенная концепция заключается в том, что вы предполагаете, что могут быть закрыты только полные сегменты - что не соответствует действительности. Незаполненный сегмент будет закрыт при передаче segment.ms или retention.ms. - person Matthias J. Sax; 09.12.2016
comment
Подумайте об этом следующим образом: если у вас есть открытый сегмент, и время хранения прошло, Kafka хочет его удалить. Поскольку он может удалять только закрытые сегменты, он просто закрывает сегмент, чтобы сделать его доступным для удаления. Так что, возможно, утверждение, что только те сегменты, которые были закрыты, могут быть кандидатами на удаление, является ошибочным, поскольку, по вашему мнению, это означает, что текущий открытый сегмент защищен от времени хранения. Но этого подтекста нет - и Тодд не утверждал, что этот подтекст есть - его формулировка верна; возможно, трудно понять. - person Matthias J. Sax; 09.12.2016
comment
Тогда соглашаемся. Итак, мой последний вопрос, смешивающий то, что сказали Tood и вы, заключается в том, будет ли хотя бы сегмент удален, если все сообщения в сегменте старше, чем (в данном случае) retention.ms. согласно моему тестированию, я бы сказал да. - person Columb1a; 10.12.2016
comment
Я знаю, что это очень старый пост, но, поскольку он проливает много света и мудрости по этому поводу, было бы хорошо уточнить, когда retention.ms начинает считаться. С момента открытия сегмента или с момента написания в него последнего сообщения? - person alianos-; 08.02.2018
comment
Учитывается последнее написанное сообщение - если будет использовано время начала, сообщения могут быть удалены слишком рано. Обратите внимание, что задержка в миллисекундах является гарантией нижней границы, и данные будут храниться, по крайней мере, в течение этого времени. - person Matthias J. Sax; 09.02.2018
comment
Иногда (для более низкого retention.ms) может также случиться, что даже до того, как данные будут сброшены на диск, сегмент может быть помечен как закрытый. Кафка сбрасывает на диск и удаляет их или напрямую очищает буферную память? - person JavaTechnical; 02.04.2019

arrow_upward
3
arrow_downward

Есть одна конфигурация брокера - log.retention.check.interval.ms, которая влияет на этот тест. По умолчанию это 5 минут. Таким образом, сегменты журнала брокера проверяются каждые 5 минут, чтобы узнать, можно ли их удалить в соответствии с политиками хранения.

В конфигурации topic1 была установлена ​​политика хранения (retention.ms = 60000), поэтому, если было хотя бы одно существующее сообщение в активном сегменте topic1, этот сегмент закрывался и удалялся, если он простаивал долгое время. достаточно. Поскольку log.retention.check.interval.ms - это конфигурация брокера, на нее не влияют изменения в теме. Кроме того, retention.ms должен пройти после того, как в сегмент будет создано последнее сообщение. Таким образом, после создания последнего сообщения для этого сегмента, сегмент будет удален не менее чем за retention.ms миллисекунды и не более чем через retention.ms + log.retention.check.interval.ms.

Таким образом, «сегмент всего из 35 байтов, который содержал только одно сообщение, был удален через минуту (может быть, немного больше)» произошел, потому что случайная проверка хранения произошла почти сразу после того, как сообщение было создано для этого сегмента. Затем брокеру нужно было просто подождать 60 секунд, чтобы убедиться, что для этого сегмента не будет создано новое сообщение (в этом случае удаление не произойдет), и, поскольку его не было, он удалил сегмент.

Остальные конфигурации topic1 здесь не играли особой роли.

file.delete.delay.ms = 40000 только что определил, что после того, как брокер уже решил удалить этот сегмент, он должен подождать 40 секунд, чтобы сделать это.

segment.bytes = 400000 не повлияло на этот тест. Он определяет, что после того, как в сегменте будет сохранено 400000 байт, он должен быть закрыт, а новый должен быть развернут.

person sowieso-fruehling    schedule 14.09.2018