лидером для топиков, участвовать в координации группы консьюмеров?
Я понимаю, что получить ответ на канале - это привилегия. И что с глупыми и неправильными вопросами вопрошающий идет в сад. Но из молчания, к сожалению, не могу сделать верный вывод - я задал глупый/неправильный вопрос или ответ лежит где-то на поверхности в документации и мне просто в rtfm. Направьте, пожалуйста. По предварительным поискам у меня сложилось впечатление, что без чтения исходных кодов на этот вопрос просто по документации ответ не получить
Лидер он же среди консьюмеров, а координатор среди брокеров, нет ?
у вас топик из одной партиции? если нет, то он размазан по нескольким брокерам и лидеры партиций обычно тоже
Я думаю, никто не ответил, потому что с ходу ответа нет, никаких привилегий тут точно нет, мне кажется :)
Придется детально разбираться. Потому что мы наткнулись на ситуацию, когда после выпадения и возвращения в кластер брокер перестал быть лидером для своих топиков. И отказывался принимать новые данные в зоокипере из-за того, что считал свои более свежими. Это вроде как бага, понятно. Но как такой неконсистентый брокер может участвовать в координации группы консьюмеров мне пока не понятно. У нас на фоне этого(пока не знаю, в следствие ли этого) происходила постоянная перебалансировка группы и чтение топиков стало колом. Рестарт проблемного брокера проблему решил. Буду думать, что с этой радостью делать дальше
1. После выпадения\возвращения брокера лидеры, уехавшие на другие брокеры не вернулись обратно, вы это имели ввиду? 2. Брокер вернулся в кластер, но на него не доехали данные? unclean.leader.election.enable какой стоит? и какой конфиг кластера - реплики, min.isr 3. Гугление мне выдало вот эту статью, мне кажется там хорошо расписан процесс heartbeat между брокером - консьюмер-группой https://chrzaszcz.dev/2019/06/kafka-heartbeat-thread/
Вот тут достаточно хорошо рассказано про consumer group coordination https://youtu.be/QaeXDh12EhE
1. Да. 2. Да, брокер вернулся, но данные не доехали, он их отказывался принимать. unclean.leader.election.enable не стоит. Кластер из трех нод, у всех топиков одна партиция, фактор репликции три, min-isr=2 Topic:xxx.metrics PartitionCount:1 ReplicationFactor:3 Configs: Topic: xxx.metrics Partition: 0 Leader: 2 Replicas: 2,3,1 Isr: 3,1,2 3. Спасибо большое за ответы, внимательно изучу
Ну почему лидеры не вернулись понятно, брокер не встроился обратно в кластер. А вот почему это произошло - надо изучать, логи кафки посмотреть. Выпавший брокер не был контроллером кластера, случаем? unclean.leader.election.enable я, кстати, бы проверил на всякий случай, тк в ранних версиях кафки он по дефолту true, а в старших уже false, не скажу точно с какой версии
Кажется после v1.0 уже false
С версии 0.11 (см. KIP-106).
если ничего специально не делать, то любой брокер может быть координатором для любой консумер группы, всё зависит от того как хешкод ляжет. Есть такой служебный топик consumer_offsets, он как р другие топики побит по партициям, подефолту на 51 партицию если память мне не изменяет. Любая консумер группа прибивается к конкретной партиции consumer_offsets и тот брокер который является лидером этой служебной партиции тот и будет координатором группы, всё комитеты и запрос текущих офсетов будет идти через него.
Обсуждают сегодня