Kafka acks=all and min.insync.replicas durability gap

Question

Producer Durability Configuration
In Apache Kafka, the acks=all producer setting is intended to ensure that a record is acknowledged only after it has been written to the full set of in-sync replicas (ISRs). However, the actual durability guarantee is dependent on the broker-side min.insync.replicas configuration.

Environment Divergence
In a local development environment consisting of a single broker, acks=all behaves identically to acks=1 because the ISR set contains only the leader. This configuration masks potential production issues where a multi-node cluster may be configured with a min.insync.replicas value greater than one.

If the number of available replicas falls below the min.insync.replicas threshold, the producer may encounter a NotEnoughReplicasException, despite the acks=all setting being active.

How does the interaction between acks=all and min.insync.replicas affect producer availability during broker failures?
What is the recommended verification method to ensure durability guarantees are active before deploying to a multi-node production cluster?

Tasadduq Burney · Answer

Answer
With acks=all the producer waits for the leader to replicate the record to all replicas that are currently in the In‑Sync Replica (ISR) set. The broker‑side min.insync.replicas defines the minimum ISR size required for the acknowledgment to be granted. If the ISR size falls below this threshold (e.g., after broker failures), the broker returns NotEnoughReplicasException and the producer either blocks or receives an error, even though acks=all is set.
Confirmed facts

acks=all → producer acknowledgment after leader has written to all current ISR replicas.
min.insync.replicas → minimum ISR size that must be met for the broker to allow the acknowledgment.
If ISR size < min.insync.replicas, broker returns NotEnoughReplicasException to the producer.

Likely explanation
In a single‑broker development setup the ISR contains only the leader, so acks=all behaves like acks=1 and hides the dependency on min.insync.replicas. When moving to a multi‑node cluster, a broker failure that reduces the ISR below the configured threshold will cause the producer to lose availability (block or error) while the durability requirement is still satisfied for the replicas that remain in sync.
Verification steps for production readiness

Deploy a test cluster with at least three brokers, set replication factor ≥ 3 and min.insync.replicas to the value you intend to use in production (e.g., 2).
Confirm that all replicas for a topic are in the ISR (e.g., via kafka-topics --describe showing ISR count equals replication factor).
Produce records with acks=all using a simple producer client.
Stop one broker; observe that the producer continues to acknowledge as long as the ISR size remains ≥ min.insync.replicas.
Stop a second broker so that the ISR size drops below min.insync.replicas; the producer should start receiving NotEnoughReplicasException or block, confirming the durability‑availability trade‑off.
Check broker logs for ISR changes and producer client logs for timestamps or exceptions to verify the behavior aligns with the configured threshold.

These steps let you validate that the durability guarantee is active and understand the availability impact before moving to production.

Kafka acks=all and min.insync.replicas durability gap

Producer Durability Configuration

Environment Divergence

1 answer

Answer

Confirmed facts

Likely explanation

Verification steps for production readiness

Your perspective belongs here.

0 question comments