A payment system cannot treat a write as successful if too few copies remain available. The topic setting min.insync.replicas specifies how many replicas must be in sync for a producer using acks=all to receive an acknowledgment. If the threshold is not met, the producer receives an error and may retry. The setting does not provide this protection with other acknowledgment strategies. section 5.1.2 section 16.1.2
$ kafka-topics.sh \
--create \
--topic products.prices.changelog.min-isr-2 \
--replication-factor 3 \
--partitions 3 \
--config min.insync.replicas=2 \
--bootstrap-server localhost:9092
Create a three-partition topic with three replicas per partition and a minimum of two in-sync replicas. section 5.1.2
With all three brokers available, each partition has three in-sync replicas. After two brokers stop, the remaining broker becomes leader, but each partition has only one in-sync replica. The replica count configured for the topic has not changed; the number currently in sync has. section 5.1.2
$ kafka-broker-stop.sh 3
$ kafka-broker-stop.sh 2
$ kafka-topics.sh \
--describe \
--topic products.prices.changelog.min-isr-2 \
--bootstrap-server localhost:9092
Topic: products.prices.changelog.min-isr-2 PartitionCount: 3
ReplicationFactor: 3 Configs: min.insync.replicas=2
Topic: products.prices.changelog.min-isr-2 Partition: 0
Leader: 1 Replicas: 1,2,3 Isr: 1
Topic: products.prices.changelog.min-isr-2 Partition: 1
Leader: 1 Replicas: 2,3,1 Isr: 1
Topic: products.prices.changelog.min-isr-2 Partition: 2
Leader: 1 Replicas: 3,1,2 Isr: 1
Compare the Replicas and Isr fields after the shutdown: three assigned replicas remain, but only broker 1 is in sync. section 5.1.2
$ kafka-console-producer.sh \
--topic products.prices.changelog.min-isr-2 \
--bootstrap-server localhost:9092 \
--producer-property acks=all
>cola all
>[…] WARN [Producer clientId=console-producer] Got error produce response
with correlation id 10 on topic-partition
products.prices.changelog.min-isr-2-2, retrying (2 attempts left).
Error: NOT_ENOUGH_REPLICAS
(org.apache.kafka.clients.producer.internals.Sender)
[…] WARN [Producer clientId=console-producer] Got error produce response
with correlation id 11 on topic-partition
products.prices.changelog.min-isr-2-2, retrying (1 attempts left).
Error: NOT_ENOUGH_REPLICAS
(org.apache.kafka.clients.producer.internals.Sender)
[…] WARN [Producer clientId=console-producer] Got error produce response
with correlation id 12 on topic-partition
products.prices.changelog.min-isr-2-2, retrying (0 attempts left).
Error: NOT_ENOUGH_REPLICAS
(org.apache.kafka.clients.producer.internals.Sender)
[…] ERROR Error when sending message to topic
products.prices.changelog.min-isr-2 with key: null, value: 8 bytes with
error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)
org.apache.kafka.common.errors.NotEnoughReplicasException: Messages are
rejected since there are fewer in-sync replicas than required.
A producer using acks=all now receives NOT_ENOUGH_REPLICAS and retries rather than receiving an acknowledgment below the configured threshold. section 5.1.2
Choose the threshold alongside the replication factor, not in isolation:
- With replication factor 3 and min.insync.replicas=2, losing one broker leaves writes available; losing a second blocks acks=all producers. Consumers can continue while a leader remains. section 16.1.2
- With replication factor 4 and the same minimum of 2, writes can continue after two broker failures, at greater cluster cost. More replicas address broker failures, not human mistakes. section 16.1.2
Together with acks=all, a reasonable minimum such as 2 supports at-least-once delivery, but retries can still produce duplicates. If duplicates matter, consider producer idempotence as a separate measure. section 5.1.3
