Рівень Junior

Визначення

Реплікація — це копіювання даних партицій на кілька брокерів для відмовостійкості.

Партиція 0:
  Broker A → Leader (приймає запис)
  Broker B → Follower (копія)
  Broker C → Follower (копія)

Навіщо потрібна реплікація?

Якщо лідер впаде:
  Один з фолловерів стане новим лідером
  Дані не втрачаться (за умови unclean.leader.election.enable=false і наявності синхронних реплік).
  Консьюмери продовжать читання

Replication Factor

replication-factor=3 → 3 копії на різних брокерах
replication-factor=1 → немає відмовостійкості

Приклад створення топика

kafka-topics.sh --create \
  --topic orders \
  --partitions 3 \
  --replication-factor 3 \
  --bootstrap-server localhost:9092

---

Коли НЕ потрібен високий replication factor

1. Dev/test оточення — RF=1 допустимий
2. Великооб’ємні метрики/логи де втрата допустима — RF=1 або 2
3. Обмежені ресурси — кожна репліка = xN дисковий простір

---

Рівень Middle

Leader і Followers

Partition 0:
  Broker 1 → Leader (read/write)
  Broker 2 → Follower (read-only, реплікує від лідера)
  Broker 3 → Follower (read-only, реплікує від лідера)

Усі записи йдуть через лідера
Follower'и пасивно копіюють дані

ISR (In-Sync Replicas)

ISR — список реплік, які синхронізовані з лідером

Приклад:
  Leader: Broker 1
  ISR: [Broker 1, Broker 2, Broker 3]

Якщо Broker 3 відстає:
  ISR: [Broker 1, Broker 2]

min.insync.replicas

Мінімальне число реплік в ISR для запису

min.insync.replicas=2:
  acks=all + мінімум 2 репліки в ISR
  Якщо ISR < 2 → запис відхиляється

Failover

Leader впав:
  Controller брокер вибирає нового лідера з ISR
  Автоматичний процес
  Консьюмери і продюсери перемикаються

Типові помилки

1. Маленький replication factor:

   replication-factor=1 → немає відмовостійкості
   При падінні брокера дані втрачені
   

2. min.insync.replicas=1 з acks=all:

   Немає захисту від втрати даних
   Leader впав → дані втрачені
   

---

Рівень Senior

Leader Election

Controller Broker:

Один з брокерів — контролер кластера
Відповідає за:
- Вибір лідерів для партицій
- Управління ISR
- Обробку failover

При падінні контроллера → новий контролер вибирається

Leader Election Process:

1. Leader впав
2. Controller виявив падіння
3. Вибирає нового лідера з ISR
4. Оновлює metadata
5. Продюсери і консьюмери перемикаються

ISR Management

Expanding ISR:

Follower наздогнав лідера → додається в ISR

Shrinking ISR:

Follower відстає → виключається з ISR
Критерій: replica.lag.time.max.ms (30 секунд за замовчуванням)

Cross-Datacenter Replication

MirrorMaker 2:

(доступний з Kafka 2.4, замінює застарілий MirrorMaker 1)
Реплікація між дата-центрами
Active-passive або active-active topology
Асинхронна реплікація

Considerations:

- Network latency між DC
- Bandwidth costs
- RPO (Recovery Point Objective)
- RTO (Recovery Time Objective)

Production Configuration

# Topic level
replication-factor: 3
min.insync.replicas: 2

# Broker level
unclean.leader.election.enable: false
replica.lag.time.max.ms: 30000

Best Practices

✅ RF=3 для production
✅ min.insync.replicas=2
✅ acks=all для критичних даних
✅ unclean.leader.election.enable=false
✅ Рівномірний розподіл лідерів
✅ Моніторинг ISR shrink/expansion

❌ RF=1 для production
❌ min.insync=1 з acks=all
❌ Unclean leader election
❌ Ігнорування ISR shrink
❌ Один дата-центр для критичних даних

Архітектурні рішення

1. RF=3 — стандарт для production
2. min.insync.replicas=2 — баланс між availability і durability
3. Cross-DC replication — для disaster recovery
4. ISR monitoring — ранній індикатор проблем

Резюме для Senior

• Реплікація — основа відмовостійкості Kafka
• ISR — критичний механізм для consistency
• Leader election з ISR гарантує відсутність втрати даних
• Cross-DC replication для disaster recovery
• Monitoring ISR health обов’язковий для production

---

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

• Реплікація = копіювання даних партицій на кілька брокерів для відмовостійкості
• Replication Factor (RF): RF=3 — стандарт для production, витримує падіння 2 брокерів
• Leader приймає read/write, Followers пасивно копіюють дані
• ISR (In-Sync Replicas) — репліки, синхронізовані з лідером
• min.insync.replicas=2 при RF=3: запис відхиляється якщо ISR < 2
• unclean.leader.election.enable=false — лідер тільки з ISR, інакше data loss
• При падінні лідера: Controller вибирає нового лідера з ISR

Часті уточнюючі запитання:

• Що буде при RF=1? — Немає відмовостійкості, при падінні брокера дані втрачені.
• Навіщо min.insync.replicas=2? — Захист від запису в єдину копію (leader впав = data loss).
• Що таке unclean leader election? — Лідер з non-ISR фолловера → втрата даних.
• Як працює кросс-DC реплікація? — MirrorMaker 2: асинхронна реплікація між дата-центрами.

Червоні прапорці (НЕ говорити):

• «RF=1 достатньо для production» — немає відмовостійкості
• «Усі репліки приймають запис» — тільки Leader, Followers read-only
• min.insync.replicas=1 з acks=all — немає захисту від втрати даних
• «Unclean leader election — безпечний» — дані втрачені при選舉

Пов’язані теми:

• [[17. Що таке leader і follower репліки]]
• [[18. Що таке ISR (In-Sync Replicas)]]
• [[19. Як Kafka забезпечує відмовостійкість]]
• [[20. Що таке producer acknowledgment і які режими існують (acks=0,1,all)]]