Это два разных вопроса?

Это 2 вопроса об одном

Если банально - у меня прилетает Json без схемы, но я должен записать его в Postgres, которому нужна схема

Соответственно в обработке Kafka Streams мне надо добавить схему - но как это сделать?

Почему так ? Сделал сейчас пример. Создал топик- 3 партиции. Фактор репликации 2! , А брокер 1. И он продюсер смог все записать

так нету мертвых брокеров

Но фактор репликации больше ,чем Isr

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

А на этапе создания брокеры были. Создал . Стал записывать и вот теперь один брокер , но все пишется .

acks выставлен в 1

На продюсере

и в чем вопрос?

сами же запросили достаточно ответа от одного чтобы запись/комит прошёл?

Получается, что так . Но это неожиданно. Т.е RF никак не влияет на количество брокеров на которые надо записать

rf это сколько всего реплик хочется иметь в кластере
isr сколько реплик ожидаете в insync моде (без Unclean leader election потерять можно isr-1 реплик)
ask полиси определяет после какого количества confirm от реплик сообщение о записи уходит на клиент

Acks 0 (NONE)
The acks=0 is none meaning the Producer does not wait for any ack from Kafka broker at all. The records added to the socket buffer are considered sent. There are no guarantees of durability. The record offset returned from the send method is set to -1 (unknown). There could be record loss if the leader is down. There could be use cases that need to maximize throughput over durability, for example, log aggregation.

Acks 1 (LEADER)
The acks=1 is leader acknowledgment. The means that the Kafka broker acknowledges that the partition leader wrote the record to its local log but responds without the partition followers confirming the write. If leader fails right after sending ack, the record could be lost as the followers might not have replicated the record yet. Record loss is rare but possible, and you might only see this used if a rarely missed record is not statistically significant, log aggregation, a collection of data for machine learning or dashboards, etc.

Acks -1 (ALL)
The acks=all or acks=-1 is all acknowledgment which means the leader gets write confirmation from the full set of ISRs before sending an ack back to the producer. This guarantees that a record is not lost as long as one ISR remains alive. This ack=all setting is the strongest available guarantee that Kafka provides for durability.
This setting is even stronger with broker setting min.insync.replicas which specifies the minimum number of ISRs that must acknowledge a write. Most use cases will use acks=all and set a min.insync.replicas > 1.

rf/isr/ask в этом плане похожи на уровень репликации в кассандре
у вас есть уровень репликации
и есть гарантии на запись/чтение (отправил и не жду ничего, записать хоть на мастер, запишем локальный кворум, запишем кворум между датацентров)

то есть даже acks=all не гаранитирует что все реплики запишут на диск
диль что isr реплики сделают это

если реплик достаточное количество (заботитесь о сохранности данных)
но не хотите сильно проседать по производительности

то выставляется что-то вроде RF=5, ISR=3, ASK=all
всего размазано по кластеру 5 реплик
запись проходит в лидер + 2 резервные, после этого считается успешно
потерять можем по быстрому 2 машинки
потом остальные реплики тоже догонятсядо isr и опять можем терять еще 2 машинки
но тут уже запись встанет, 1 доступная реплика, с ask=all уже писать нельзя, но с ask=1 можно, так же и читать можно с этой партиции

итого в определенных условиях до 4 машин можно потерять

но нельзя потерять сразу 3 машинки, так может оказаться что они все были из isr и у вас нету последних данных

Nikolay как-то так

Спасибо. У меня 2 дата центра. Стоит задача выбрать конфигурацию. Это или 2 брокера или 4 брокерами. Вот проверяю резные варианты.