Репликация и ISR: как не терять данные

Урок про то, как Kafka переживает падение брокеров, не теряя записанные события.

Репликация — хранение копий каждой партиции на нескольких брокерах; одна реплика — лидер (через неё идут запись и чтение), остальные — фолловеры, догоняющие лидера. Синхронные реплики образуют ISR (in-sync replicas).

Зачем это нужно

Диски ломаются, серверы падают, дата-центры теряют питание. Если партиция жила на одном брокере и он умер — данные потеряны. Репликация хранит копии партиции на разных брокерах, чтобы падение одного не стоило ни байта.

Лидер и фолловеры

  Партиция P0, replication-factor = 3:

  Broker 1:  [P0 ЛИДЕР]   <- запись и чтение идут сюда
  Broker 2:  [P0 follower] <- тянет копию с лидера
  Broker 3:  [P0 follower] <- тянет копию с лидера

  Лидер упал -> один из ISR-фолловеров становится лидером.

Продюсеры и консьюмеры всегда работают с лидером партиции. Фолловеры лишь реплицируют лог лидера, чтобы быть готовыми подхватить роль.

ISR — синхронные реплики

ISR — это реплики, которые «не отстали» от лидера (догнали его в пределах допустимого лага). Когда продюсер шлёт с acks=all, запись считается успешной, лишь когда её получили все реплики из ISR. Если фолловер отстал — он временно выпадает из ISR и не блокирует запись, но и не считается надёжной копией.

min.insync.replicas

Параметр min.insync.replicas задаёт минимальное число синхронных реплик для успешной записи с acks=all. Классика для надёжности: replication-factor=3 и min.insync.replicas=2. Это значит: запись принимается, пока живы хотя бы 2 копии — один брокер можно потерять без остановки записи и без потери данных.

Настройка	Значение	Смысл
replication.factor	3	3 копии партиции
min.insync.replicas	2	пишем, пока живы хотя бы 2
acks (продюсер)	all	ждать подтверждения от ISR

Как работает под капотом

Фолловеры активно тянут данные с лидера так же, как обычные консьюмеры — запрашивая записи начиная со своего оффсета. Лидер отслеживает, до какого оффсета догнал каждый фолловер, и вычисляет high watermark — оффсет, реплицированный во все ISR. Консьюмеры видят сообщения только до high watermark: пока запись не реплицирована в ISR, она «невидима», и потому переживёт смену лидера. Если все ISR, кроме лидера, отвалились и min.insync.replicas не набирается, продюсер с acks=all получает ошибку — Kafka предпочтёт отказать в записи, чем принять её небезопасно.

Частые ошибки

replication-factor=1 на проде. Падение брокера = безвозвратная потеря партиции.
min.insync.replicas=1 при RF=3. Формально 3 копии, но запись подтверждается одной — теряется при неудачной смене лидера.
Реплики на одной стойке/AZ. Сбой стойки убьёт все копии; разносите по зонам отказа.

Итоги

Репликация хранит копии партиции на нескольких брокерах; запись/чтение идут через лидера.
ISR — синхронные реплики; acks=all + min.insync.replicas=2 при RF=3 переживают потерю брокера.
Консьюмеры видят данные только до high watermark — реплицированные во все ISR.