Я нигде не могу найти документально подтвержденное, но что делает Кафка с записями, которые больше не доступны?
Я обнаружил, что могу создавать записи по сжатой теме на Кафке v1.1кластера, настройте тему для cleanup.policy=delete и используйте метод v1.1 AdminClient.deleteRecords(), чтобы «удалить» записи из разделов темы и, наконец, восстановить конфигурацию cleanup.policy=compact.
На самом деле, кажется, что происходит за кулисами, а не удаление записей из сегментов журнала, Kafka увеличивает начальное смещение для каждого раздела до значения, которое вы предоставляете с помощью метода deleteRecords:
[2019-02-07 01:46:55,282] INFO [Log partition=delete-records-compact-topic-2, dir=/data/kafka] Incrementing log start offset to 505317 (kafka.log.Log)
[2019-02-07 01:46:55,295] INFO [Log partition=delete-records-compact-topic-1, dir=/data/kafka] Incrementing log start offset to 485663 (kafka.log.Log)
[2019-02-07 01:46:55,298] INFO [Log partition=delete-records-compact-topic-3, dir=/data/kafka] Incrementing log start offset to 478872 (kafka.log.Log)
Новые потребители будутначните чтение с этих начальных смещений, чтобы записи эффективно удалялись с их точки зрения, но данные в файлах журналов все еще там.Поскольку данные в файлах журналов не удаляются вызовом API deleteRecords и компактная тема не подлежит хранению, будут ли данные в файлах журналов храниться вечно до тех пор, пока существующие ключи не будут обновлены и не произойдет сжатие?Или очиститель журнала / планировщик со временем удалит его, так как записи до начального смещения больше не будут доступны потребителям?
Я не совсем следую поддерживаемому шаблону, так как метод AdminClient.deleteRecords выдает исключение PolicyViolationException, еслитема по-прежнему настроена на cleanup.policy=compact, но этот метод для меня будет намного проще, чем метод очистки тем на основе хранения или метод удаления / воссоздания тем.