(все равно смущает, что replication factor = 4, но реплик у партиции всего 2)
Если не брать в расчет текущее количество реплик партиции, то по идее, в isr должно стать 2 само, когда вторая реплика догонится и если между брокерами нет каких-то проблем, связанных с репликацией. При min.insync.replicas=2 ошибки должны уйти

спасибо. да встало само через некоторое время

подскажите пожалуйста, как лечить топики с партициями где Leader -1?

/kafka --describe --unavailable-partitions
Topic: ads  Partition: 1 Leader: -1 Replicas: 10,3,23 Isr: 3

Кто-то делал что-то типа такого?

Есть кафка в качестве шины. Есть два сервиса.
Есть ивент А, который уходит с первого сервиса на второй.
Нужно после окончания обработки этого ивента еще отправлять ивент B с первого сервиса на второй. (что-то по типу цепочки ивентов).
Что-то я не могу найти подобного решения в интернете.

Пока что как решение вижу - отправлять со второго сервиса на первый сообщение об окончании обработки ивента А, и соответственно реагировать на это в первом сервисе.

gRPC без кафок справляется с таким

А как ты на первом сервисе поймешь, что обработка завершена?
И почему сразу не кинуть событие A и B с первого сервиса и просто на втором сервисе не брать B, пока не обработал A ?

Понять можно, отправив со второго сервиса ивент о завершении работы.

Можно и два сразу послать, в принципе, только все-равно их надо выполнять последовательно

ну так кидайте в одну партицию, и будете обрабатывать их последовательно

Если у тебя это единичный случай, то посмотреть по логом причины, всё с связано с этим топиком, так же что с остальными двумя брокерами точно ли норм.
Поискать кто был последний лидер до проблемы, это явно не 3 будет
Можно рестартануть брокер где находился лидер.
если он скорее мёрт чем жим, то выставить на топик unclean.leader.election.enable=true, он должен отлипнуть, и перейти на одну из живых реплик, но ты должен понимать, что тут в 99.9 будет потеря данных которые не реплицировались во время падения, если у тебя ack=1 в продюсере, то возможно это и не проблема. После восстановления работы, не забудь убрать unclean.leader.election.enable с топика

Коллеги, подскажите, а можно включить в кафке сжатие налету? Ну у меня например рабочая кафка с 3ТБ данных. Если я включу сжатие, это не вызовет странных событий?

Коллеги, подскажите, можно ли настроить репликацию между кластерами без SSL?

По умолчанию на стороне брокера compression.type=producer. В целом, можно поменять, тогда просто новые данные будут сжиматься так, как захотите, но это увеличит нагрузку на брокер.
Обычно на продюсерах компрессию ставят, чтобы уже сжатые данные сохранялись без необходимости брокеру сжимать их самостоятельно (хотя разжимать ему приходится все равно для валидации)

валидации на брокере ж вроде в ванильной кафке нет?

схемы реджистри? нет

Добрый день, коллеги. Подскажите, пожалуйста, на вашей практике, к каким именно проблемам в работе кафки приводили проблемы в работе зоокипера(затыки в работе дисковой подсистемы)?

Привет. Использую Kafka перед Elasticsearch. После временной потери связности по сети с Elastic, кафка не восстанавливает коннект с Elasticsearch. Рестарт кафки решает проблему. Такое поведение встречается у кого-то?

А что используется для связи кафки с эластиком? Там и искать

Юзаю kafka-connect-elasticsearch . Пока не удалось определить по логам в чем ошибка. Если это не типичное поведение kafka-connect и это только у нас, то пойду дальше копать.

Помогает перезапуск кафки или kafka-connect?