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

В прошлом уроке мы разобрались, как консьюмер не теряет своё место в логе. Но лог хранится на диске брокера, а диск может сгореть, и сервер может перезагрузиться посреди рабочего дня. Отто спрашивает прямо: если ночью упадёт один из трёх серверов Kafka, пропадут ли оплаты за вечер? Сегодня разберём, почему не пропадут и при каких настройках.

Главная книга и два помощника

Представь бухгалтерию с главной книгой. Записи в неё вносит главный бухгалтер. Рядом сидят два помощника и переписывают каждую новую строку в свои копии книги. Если главбух заболел, книгу берёт помощник, у которого копия полная, и работа продолжается.

Важно, кто считается помощником «с полной копией». Помощник, который ушёл на обед и отстал на двадцать строк, книгу принять не может: в его копии нет последних записей. Поэтому главбух держит на столе список тех, кто сейчас успевает. Отстал помощник, его вычёркивают из списка; догнал, вписывают обратно.

Kafka устроена так же.

Реплики, лидер и фолловеры

Каждая партиция топика хранится в нескольких копиях на разных брокерах. Копию называют репликой, а сколько их, задаёт фактор репликации, мы встречали его в уроке про топики и партиции.

Одна реплика главная, это лидер: в неё пишут продюсеры и из неё читают консьюмеры. Остальные реплики называют фолловерами. Фолловер всё время спрашивает у лидера «что нового?» и дописывает к себе.

Список реплик, которые успевают за лидером, называется ISR, in-sync replicas. Это и есть список на столе главбуха. Лидер всегда в нём. Фолловер вылетает из ISR, если отстаёт дольше replica.lag.time.max.ms (30 секунд по умолчанию) или если его брокер умер.

Что видят консьюмеры

Новая запись сначала попадает только к лидеру, потом фолловеры её копируют. Пока копия есть не у всех реплик из ISR, консьюмеры эту запись не получают. Граница «до сюда записи есть у всех из ISR» называется high watermark.

Зачем такая осторожность? Если бы консьюмер прочитал запись, которая есть только у лидера, а лидер тут же умер, новый лидер этой записи не знал бы. Биллинг списал бы деньги за оплату, которой в Kafka больше нет. High watermark не даёт прочитать то, что ещё может пропасть.

Когда брокер умирает

Брокеры постоянно отмечаются у контроллера кластера. Если брокер молчит дольше broker.session.timeout.ms, 9 секунд по умолчанию, контроллер его огораживает: убирает из ISR всех партиций. Если брокер был лидером, контроллер назначает лидером другую реплику из ISR. Поскольку в ISR только реплики со всеми записями, новый лидер ничего не теряет.

Мы проверили это на настоящем кластере из трёх брокеров Kafka 4.3.1. До падения:

Topic: payments	Partition: 0	Leader: 3	Replicas: 3,1,2	Isr: 3,1,2	Elr: 	LastKnownElr: 

Остановили брокер 3, лидера, и через десять секунд:

Topic: payments	Partition: 0	Leader: 1	Replicas: 3,1,2	Isr: 1,2	Elr: 	LastKnownElr: 

Лидером стал брокер 1, ISR сократился до двух реплик, все оплаты на месте.