Нет, оно не будет доступно (записано) до тех пор пока все isr не запишут эту запись

С другой стороны до этого момента не придёт подтверждение продьюсеру, что запись прошла

Нельзя прочитать что не записано :)

Если я пишу в момент 0 и все 5 брокеров рабочие, но один отстает на 5 секунд, то продюсер прекрасно запишет и получит ACK обратно.
Но консюмеры не увидят эту новую запись еще 5 секунд.

А то, что у меня фактор репликации 4, а доступно только 3 брокера ? Это норм ?

We can now more precisely define that a message is considered committed when all in sync replicas for that partition have applied it to their log. Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand, have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the producer uses. Note that topics have a setting for the "minimum number" of in-sync replicas that is checked when the producer requests acknowledgment that a message has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed, even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader).

The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times.

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

Ну то что ты скинул как раз соответствует тому что выше написано

От @xhumanoid

Если все isr и ask all то не получите

Запрос на записке на продьюсере будет висеть и ждать

Это случай когда нету isr реплик и часто ставят dirty leader election

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

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

С unclear leader election выберется тот который больше данных держит и полетите дальше, допустима потеря данных

конкретно для данного кейса:

читать вы будете всегда
писать как получится, зависит от распределения insync реплик
https://kafka.apache.org/documentation/#design_ha
второй пункт
However, it reduces availability since the partition will be unavailable for writes if the number of in-sync replicas drops below the minimum threshold.

часть по выбору какая реплика insync, какая просто подтягивается я не помню, вроде всё назначается сразу и управляется в полуручном режиме =\

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

по поводу Unclean leader election

However a practical system needs to do something reasonable when all the replicas die. If you are unlucky enough to have this occur, it is important to consider what will happen. There are two behaviors that could be implemented:

1. Wait for a replica in the ISR to come back to life and choose this replica as the leader (hopefully it still has all its data).
2. Choose the first replica (not necessarily in the ISR) that comes back to life as the leader.

@gamussa помнишь как выборы назначение isr проходят?

Kafka takes a slightly different approach to choosing its quorum set. Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. Only members of this set are eligible for election as leader. A write to a Kafka partition is not considered committed until all in-sync replicas have received the write. This ISR set is persisted to ZooKeeper whenever it changes. Because of this, any replica in the ISR is eligible to be elected leader.

не совсем ясно даёт описание

Привет всем!

Подскажите, как сделать подобное преобразование с помощью plain Java + Kafka Streams


CREATE STREAM TESTDATA_CSV (ID INT, ARTIST VARCHAR, SONG VARCHAR) \
WITH (KAFKA_TOPIC='testdata-csv', VALUE_FORMAT='DELIMITED') -

Каким образом добавить к существующему json схему, удовлетворяющую Kafka Connect