А при unclean.leader.election.enable=true если лидер пропал, то оставшиеся реплики (которые

не insync) никак не смогут проголосовать и выбрать нового лидера самостоятельно?
Надо принудительно вызывать голосование с unclean флагом?

как раз наоборот, если unclean.leader.election.enable=true, то лидер будет выбран автоматически (с потерей данных, если реплика была не insync).

у меня что-то автоматом это не происходит. Какой-то таймаут может есть - не могу в доке найти...

а что происходит? Опишите процесс. Логи\метрики есть?

есть 3 брокера + 3 контроллера kraft - версия 3.5.1 Настройки брокеров offsets.topic.replication.factor=3 transaction.state.log.replication.factor=3 transaction.state.log.min.isr=2 Действия: * делаю топик test RF=3, min.insync.replicas=2, unclean.leader.election.enable=true, partitions=3 * пишу/читаю успешно c acks=all,1 * гашу b3 * пишу/читаю успешно c acks=all,1 * гашу b2 * пишу/читаю успешно c acks=1 * гашу b1 * поднимаю b2 * тут получается b2 слегка отстал от b1 и лидером всех партиций является b1, кроме того ISR=b1 для всех партиций * Leader не выбирается. По логам смотрю - он даже не пытается выбрать лидера партиций. Elected as the group coordinator только. * я в этом месте ожидаю, что для топика test автоматом произойдет голосование.

контроллеры же на отдельных машинах? гашу b2 - на этом шаге сколько живых брокеров остается, один?

1. это всё тестовый стенд на docker compose (6 отдельных контейнеров) 2. после того как гашу b2 - остается один брокер b1

тогда я не очень понимаю, как происходит запись на этом шаге - у вас minisr=2, остается одна живая реплика, запись должна остановиться - должно выдаваться исключение. При этом чтение возможно, да

с acks=1 запись возможна. Почему она должна остановится?

А что за задача такая? Это не совсем характерное использование для кафки, я бы сказал. Всё-таки её обычно ставят с условием хоть какого-то сохранения целостности данных, и даже unclean он скорее на случай отставания по isr, но не полного пропадания связи. А в вашей ситуации вы фактически сплит-брейн эмулируете и ждёте адекватного поведения. Т.е. выпавший из кластера брокер просыпается "в одиночестве", и что он должен по вашему делать? Если он будет автоматом подниматься как кластер и начинать принимать данные, что произойдёт в случае если он отвалился по сетевой доступности от остального кластера но остался живой и доступный для части клиентов? И что произойдёт, когда связность сети восстановится?

Это синтетический тест уменьшения ISR до 1 и возникновения условий для выбора лидера. Судя по доке unclean.leader.election.enable=true говорит, что выбрать можно лидера даже если ISR меньше min.insync.replicas. Я наверное перегнул палку, т.к. судя по ситуации с топиком после поднятия одного из брокеров и даже двух (не лидера) у меня есть информация, что ISR = только одному брокеру, который я не поднял, создавая эту эмуляцию. В итоге без наличия ISR (хотя бы одного) выборов и не происходит. Но я проверил. Даже в этой ситуации - можно провести голосвание вручную и оно пройдет успешно с потерей тех данных, которые были на лидере перед его убиванием. $ kafka-topics --describe --topic test [2023-11-20 08:50:50,420] WARN Couldn't resolve server b1:9092 from bootstrap.servers as DNS resolution failed for b1 (org.apache.kafka.clients.ClientUtils) Topic: test TopicId: YqM_kYQASKKPe7FhIy641g PartitionCount: 3 ReplicationFactor: 3 Configs: min.insync.replicas=2,segment.bytes=1073741824,unclean.leader.election.enable=true Topic: test Partition: 0 Leader: none Replicas: 201,202,203 Isr: 201 Topic: test Partition: 1 Leader: 202 Replicas: 202,203,201 Isr: 203,202 Topic: test Partition: 2 Leader: none Replicas: 203,201,202 Isr: 201 Спасибо, что указали на мой перегиб!

ну вот тут я бы поспорил, что для кафки это странная ситуация. То есть сама по себе ситуация из разряда теоретических, да, но для кафки вроде как все предельно ясно: теряем все брокеры постепенно, потом один брокер оживает, unclean.leader.election.enable=true - он становится лидером, его набор данных будет истиной, все что пришло уже после в последний вырубившийся брокер отбрасывается. Провел точно такой же эксперимент (kafka 2.8.2 на зукипере) - 3 брокера, топик с rf=3 и min.insync=2 (не знаю, зачем это указал, все ранво ack=1 поставил) 1. Пишем\читаем (одной cg) в три брокера (консольные утилиты): Пишем: 1 2 3 Читаем: 1 2 3 2. Выключаем лидера broker500 (партиция одна в топике), остаются два брокера Пишем 11 22 33 Читаем 11 22 33 3. Выключаем нового лидера broker300, остается один брокер Пишем a b c Читаем a b c 4. Выключаем broker400 Продюсер >[2023-11-20 15:17:59,526] WARN [Producer clientId=console-producer] Connection to node 400 (kafka-400) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient) Консьюмер >[2023-11-20 15:17:59,526] WARN [Consumer clientId=console-consumer, groupId=churkin] Connection to node 400 (kafka-400) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient) 5. Включаем broker300 Пишем aa bb cc Получаем aa bb cc 6. Включаем broker400 и broker500 Пишем 111 222 333 Получаем 111 222 333 Ну и теперь читаем полностью весь топик новой cg и видим 1 2 3 11 22 33 aa bb cc 111 222 333 То есть записи из пункта 3 потерлись Уточнение: все это сработало при установке unclean.leader.election.enable=true на брокерах. При false на брокерах и true per topic работала запись, но не работало чтение начиная с пункта 5, в чем тоже хорошо бы разобраться Извините за много букв

> в чем тоже хорошо бы разобраться посмотрите настройки топика __consumer_offsets - там после таких действий при дефолтных параметрах может не быть лидера.

Тот же вопрос - а что будет, если не выключать брокеры а просто порвать между ними сеть?

да, про consumer_offsets логично. Для него видимо тоже надо "нечистый выбор" проставлять

только между брокерами с доступом к зукиперу?

3 брокера это хрень, отказоустойчивая конфигурация 4 брокера

старые песни о главном, ставь 4, кто те мешает

Ну вот и что будет при том же сценарии? Ложится первая локация, потом вторая, потом третья. А потом поднимается только вторая. Тоже ведь кворума не будет и всё.

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

Вот. А почему в аналогичной ситуации крафт вдруг должен заработать?

ну там же товарищ выключал только брокеры, а контроллеры, которые у него отдельные, работали и ничего с ними не происходило, и поведение, по идее, должно было быть такое же, как у меня при живых зукиперах

то есть у него 6 нод, 3 под контроллеры и 3 под брокеры?