Всем привет! А кто-нибудь имел опыт обновления Kafka с 2.Х.Х версий

до 3.Х.Х или выше, какие шаги в целом, меняются ли конфиги как то сильно?
Или просто гасим и ставим новую версию и поднимаем?

вычитать всё, погасить, очистить log дир, обновить, обновирть джава на 17-19, прописать в овверайд шенадоах\згц, запустить, скриптом создать заново топики

Спасибо, топики помрут?

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

Обновлялись с 2.8 на 3.3 (с тестовыми - около 20-30 кластеров) через роллинг рестарты - проблем не заметили. Джаву обновляли заранее, отдельным таском.

А меня ли message format version? У себя в пропертях не нашёл её, в этом случае говорят что она = версии самой кафки, т.е 2.30 в моем случае. Как у вас было?

Если раньше не апгрейдили - почитайте доку Кафки. Там обычно 3 роллинг рестарта кластера. Если правильно помню, то для апгрейда бинарников, потом интерброкер протокола, потом для лог мессадж формата. Нужно ли менять формат - мы меняем. Краем глаза видел конфиги топиков в конфлюенте - у меня сложилось впечатление, что они не меняют (но могу ошибаться тут). Почитайте также чейнджлог: с версией 3.0 приехала пара значимых изменений. Про конфиги: нам какой-то класс для ACL нужно было поменять, т.к. предыдущий задеприкейтился.

fа зачем столько страданий? проще вырубить на 30 минут и за раз всё обновить

Даунтайм дорого стоит

эх, иногда у меня ощущение, что люди не понимают что пишут, 3 роллинг рестарта это мин 3 часа гемора, а если данных мало, и всё было быстро, то и стоимость даунтайма никакая

Вот и у меня такое же ощущение, что не понимают что пишут. Стоимость даунтайма бывает разная и если это шина данных для приносящих деньги бизнес приложений, то грейсфул останов и старт всего бизнеса для операций на полчаса может по себестоимости равняться паре годовых з/п девопсов. Поэтому 3 роллинг рестарта очень выгодный вариант, который в том числе можно автоматизировать. Тем же ансиблом можно проверять наличие андеррепликейтед партиций перед переходом к следующему брокеру

ну то есть, СТО вашей компании умственно отсталый, раз у вас 1 кафка кладёт всю работу приложений, и при этом она в единственном экземпляре

архитектор ж, не CTO

ну то есть у вас мало того что Архитектор безграмотное существо, так ещё и СТО его друг верно?

у нас нет. У нас например архитектор не разрешает бинари гонять в кафке (как у вас - чтобы были террабайты-то).

Ага ага, то есть, вся компания сидит и молиться на 1 шину, без которой типа за пол часа пара годовых з\п теряется, делается роллинг рестарт который кстати не сработал бы при ksqldb активном использовании, но вы говорите про бинари, которые отсылали кассы, лол

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

если обновление какой либо среды роняет всё - ващ СТО идиот, выключение любой среды на 12 часов не должно никак влиять на сервисы

почему cto? я думаю что это отвественность архитектора придумать и защитить свою архитектуру.ю

Простите, а у вас все среды обновляются одновременно? Просто даже кластер обычно обновляют по частям, с graceful shutdown и прочими предварительными ласками

Конечно по очереди. Если есть 10 сред, каждая приносит 1/10 прибыли компании, то даунтайм на 30 минут даст в среднем даунтайм на 30 минут всего прода.

чего? кто вам эту чушь сказал?даже в блокчейне и услугах продажи аналитики нет такой взаимосвязи

То есть вы всю среду сразу в даун отправляете? А зачем? Или у вас единственная инсталляция без резервирования?

Патчились с 2.8 до 3.0 Мои грабли: 1. Надо вычищать весь bin. Просто перераспаковка поверх не сработает, остаются старые артефакты которые кафка пытается пользовать. 2. Где-по середине 2.х переименовывали класс авторайзера. Но из за пункта 1 это выстрелило только пре переходе на 3.0 Ну и в целом там в 3.0 много параметров у бинарников выпилили. Чуть плейбуки править пришлось. В остальном пропатчились норм. Данные не потеряли.

данные физически потерять нельзя, формат можно хоть от 0,8,0 положить в 3 версию и всё будет работать

Тем прекрасней кафка). Но я имел ввиду что топики , ACL и тд все это тоже пережило апгрейд. Пересоздавать ничего не пришлось

я писал про пересоздание. потому что при большом кол-ве консумер групп у части групп терялись метки о том, что прочитано а что нет, а перечитать 100 тб, дольше чем пересоздать всё, хотя мы и эту проблему решили, храня номер офсета в сцилле

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