Привет, у меня вопрос к экспертам :) Кафка старая 2.0.0

при добавлении нового сервера не меняли настройки для репликации __consumer_offsets топика (системного) но при апдейте я тут решил таки его привести в состояние репликации.

Т.к кафка старая не получилось все сделать через утилиты (CMAK,kafkactl) и собственно выбрал стандартный путь по оф документации, подготовил json и bash скрипт в директории kafka - примеры json могу скинуть.

и получилось что __consumer_offsets (в нем 50 партиций) размазался на 2 брокера, но не так как наверное должно быть..
Partition Latest Offset Leader Replicas In Sync Replicas Preferred Leader? Under Replicated?
0 9 0 (0,1) (0,1) true false
1 34 1 (1,0) (0,1) true false
2 3 0 (0,1) (0,1) true false
т.е у меня Replicas размазались на два сервера с чередованием (0,1) и (1,0) но в In Sync Replicas все осталось только (0,1)

будет ли проблемой если лидер выключится (т.к топик системный в такой конфигурации) и как починить не убивая кафку?

Вообще для __consumer_offsest задается репликация в offsets.topic.replication.factor, в конфиге брокера. Но это, ясно дело, через рестарт. Я вообще удивлен, что кафка дала с ним что-то сделать через консоль

grep offsets /opt/kafka/config/server.properties # The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state" offsets.topic.replication.factor=1 т.е правильнее без json просто поменять это число на кол-во брокеров и перезапустить каждый?

А чо не-то, топик как топик. И, кстати, задание проперти и рестарт как раз ни к чему не приведёт, эти значения применяются только при создании топика. Хотите изменять уже созданный - изменяйте как и любой другой.

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

хз, помнится я как-то попробовал через cmak накинуть, получил отлуп. Но подробностей не помню. Надо потестить, может и ок.

да, сразу конфигурация была 1брокер и все топики создавались как есть 1-партиция и 1-реплика а потом уже потребовалось добавить сервер и перенастроить все что уже было на нем. все ок, но вот осталась системный топик его и пока не трогал. спасибо. но фактор лучше поменять в конфиге?

через него не все работает, у меня главная задача была увеличить кол-во реплик и он тупо ничего не делает, а kafkactl говорит про ошибку в API (хотя я и пробовал какуюто друвнюю версию)

Да, лучше поменять, но это скорее "для потомков" и в целом приведения всего в порядок, практического эффекта это не даст (опять же, насколько я помню мои собственные приключения по переходу с однонодовой инсталляции на кластер с добавлением нод на ходу).

Когда игрался с этим топиком - такие же результаты были: для существующего - через json, а строчка конфига для консистентности на случай если вдруг что-то произойдет

Приоритет при выборе лидера - в колонке Replicas (собственно у вас даже колонка есть - Prefered leader). Insyncreplicas - тут порядок не так важен (не уверен, но либо когда реплика стала инсинк, либо когда была создана). Если у вас вылетит брокер, лидером станет другая. Но помните, что есть доступность и надёжность. С 2 брокерами и 2 репликами чего-то одного у вас точно не будет при вылете 1 брокера

Окружение тестовое но немного не понял почему будет проблема. Если у меня есть 1 патриция и у нее фактор репликации 2 то копия должна храниться на соседнем брокере, и при отсутствии хоста, он может стать лидером и принимать/отдавать сообщения. Вариант с 50партициями есть только у служебного топика. Но проектные топики могут быть разделены на 2 партиции и с фактором репликации 2, т.е мне казалось что это должно обеспечить продолжение работы если вдруг хост будет перезапущен или умрет или я его отключу для техработ например.

Стикер

Так при любом количестве реплик может случиться. Просто не стоит в in-sync одну держать, минимум две, остальное - depends on, нет?

С 2 репликами на обоих стульях не получится усидеть

Ну так и с 3-мя при отвале двух нод уйдем в рид-онли

Но с 3 нодами можно настроить так, что при потере одного брокера можно сохранить доступность на запись и без потери данных. И мне показалось, что автор исходного поста хотел эти свойства с 2 репликами, чего достигнуть не получится