Т
сейчас весь трейс из либы найду
немногословно: kafka write errors (4000/307649)
вот в самой либе : https://github.com/segmentio/kafka-go/blob/0b1c833ed2f70394b8dab48939fa54a1282db956/error.go#L594
Size: a a a
2021 January 28
SB
немногословно: kafka write errors (4000/307649)
вот в самой либе : https://github.com/segmentio/kafka-go/blob/0b1c833ed2f70394b8dab48939fa54a1282db956/error.go#L594
вот в самой либе : https://github.com/segmentio/kafka-go/blob/0b1c833ed2f70394b8dab48939fa54a1282db956/error.go#L594
МДА, Гоферы не перестают удивлять.
Т
хорошо, спасибо большое за совет!
BB
Добрый вечер. Питоновская либа Кафки. Нужно получить консумер лаг на определенном топике. Есть подобное в примерах : https://github.com/confluentinc/confluent-kafka-python/blob/master/examples/adminapi.py но нюанс в том , что AdminClient не содержит такого метода. Кто-то сталкивался ? И второй вопрос : пример из конфлюента - весь стак , включая ksqldb и control center поднимается докере. При доступе с удаленной машины на ui, и попытке создании таблицы или стрима выдаётся ошибка соединения https://github.com/confluentinc/cp-all-in-one/blob/6.0.1-post/cp-all-in-one/docker-compose.yml .
Попытка номер 2.
2021 January 29
NK
MG
Всем привет! У нас есть некая система, которая читает данные из кафки и складывает в БД. Так вот, от коллег поступила идея хранить офсеты не средствами кафки, как это работает из коробки, а в самой БД. Мотивация - если мы восстановим БД из бэкапа, мы будем точно знать, с какой позиции надо прочитать топик, чтобы база пришла в косистентное состояние
MG
Может есть какие то еще варианты реализации этого? И какие возможны траблы при хранении офсетов снаружи?
t
Всем привет! У нас есть некая система, которая читает данные из кафки и складывает в БД. Так вот, от коллег поступила идея хранить офсеты не средствами кафки, как это работает из коробки, а в самой БД. Мотивация - если мы восстановим БД из бэкапа, мы будем точно знать, с какой позиции надо прочитать топик, чтобы база пришла в косистентное состояние
Как мне кажется, мотивация не много странная. Кафка изначально фолт толерант. Зачем перекладывать ответственность на БД?
MG
так уж сложилось, что БД - менее надежная)
OG
Один консумер?
SB
Всем привет! У нас есть некая система, которая читает данные из кафки и складывает в БД. Так вот, от коллег поступила идея хранить офсеты не средствами кафки, как это работает из коробки, а в самой БД. Мотивация - если мы восстановим БД из бэкапа, мы будем точно знать, с какой позиции надо прочитать топик, чтобы база пришла в косистентное состояние
Не понятно, какую проблему вы решаете. Что значит «хранить офсеты чтобы бы база пришла в консистентное состояние». Что делает состояние неконсистентнвм?
SS
Может есть какие то еще варианты реализации этого? И какие возможны траблы при хранении офсетов снаружи?
Вот у akka projections есть такие сценарии
https://doc.akka.io/docs/akka-projection/current/kafka.html#committing-offset-outside-kafka
если я правильно вопрос понял
https://doc.akka.io/docs/akka-projection/current/kafka.html#committing-offset-outside-kafka
если я правильно вопрос понял
λ
Может есть какие то еще варианты реализации этого? И какие возможны траблы при хранении офсетов снаружи?
никаких проблем нету, сортируете стрим окном, трекаете офсет для каждой партиции на етом все и атомарно пишете макс офсет для месаджа в батче для определенной партиции
ЧП
Вообще у консьюмера есть такая возможность. По апи вроде все просто
Должно работать
Должно работать
ЮБ
Всем привет! У нас есть некая система, которая читает данные из кафки и складывает в БД. Так вот, от коллег поступила идея хранить офсеты не средствами кафки, как это работает из коробки, а в самой БД. Мотивация - если мы восстановим БД из бэкапа, мы будем точно знать, с какой позиции надо прочитать топик, чтобы база пришла в косистентное состояние
Это нормальный сценарий