Что делать если в Kafka мало места при большом объеме сообщений
Что проверяют
Понимаете ли вы, что Kafka не очередь с удалением после чтения: сообщения лежат до истечения retention, а диск освобождается только при удалении закрытых сегментов. Ещё смотрят, отделяете ли вы срочное действие от системного решения, и не предложите ли сразу «добавить дисков».
Как отвечать
Сначала срочное:
- посмотреть, какие топики и партиции съели место, через
kafka-log-dirs.sh --describe, и найти перекос по партициям; - уменьшить время хранения у самых объёмных топиков на уровне топика (
kafka-configs.sh --alter --entity-type topics --add-config retention.ms=...), это применяется без перезапуска брокера; - помнить, что
retention.bytesзадаётся на партицию: у топика с двадцатью четырьмя партициями фактический объём в двадцать четыре раза больше указанного; - удаляются только закрытые сегменты, поэтому при слабом трафике старые записи лежат внутри активного файла. Помогает уменьшение размера сегмента и времени его закрытия.
Затем системное: включить сжатие на стороне продюсера (в Go-клиентах это опция продюсера, брокер по умолчанию хранит то, что прислали), укрупнить батчи, поскольку сжимается батч целиком, заменить многословный JSON на компактный бинарный формат, вынести большие объекты в объектное хранилище и слать ссылку.
Где спотыкаются
Включают компактизацию, полагая, что она сжимает данные. Она оставляет последнее сообщение по каждому ключу и годится только для топиков со смыслом снапшота состояния. На журнале событий это не экономия, а потеря истории.
Чистят диск руками, удаляя файлы сегментов. Брокер держит их открытыми и ведёт к ним индексы, после такой уборки партиция уезжает в ошибку и требует восстановления. Место освобождают настройками хранения и удалением ненужных топиков.
Планируют объём без учёта репликации и отстающих потребителей. Фактор репликации умножает занимаемое место, а медленный консьюмер ничего не удерживает: данные исчезнут по сроку хранения, и при следующем чтении он получит ошибку о недоступном смещении.