Min.insync.replicas
min.insync.replicas is a Kafka setting specifying the minimum number of in-sync replicas that must acknowledge a write for it to succeed.
Apache Kafka in Action
The minimum in-sync replicas setting specifies the smallest number of replicas that must acknowledge a write for it to succeed.
- How it is used
- Protects acknowledged writes by requiring a minimum in-sync replica count when producers use acks=all.
- How deep it goes
- Works through topic configuration, broker shutdown, ISR inspection, and producer errors; stops short of detailing replica catch-up.
- Examples
- Tests a three-replica price-changelog topic by stopping two brokers and observing NOT_ENOUGH_REPLICAS.
- What you can do after
- Operate/configure it with kafka-topics.sh and acks=all to set a failure threshold and recognize blocked writes.
Read how Apache Kafka in Action explains min.insync.replicas →
Kafka Streams in Action, Second Edition
min.insync.replicas is a Kafka topic configuration specifying the minimum number of in-sync replicas required for a write to succeed.
- How it is used
- Controls whether Kafka accepts writes when too few replicas remain in sync, especially alongside producer acknowledgments.
- How deep it goes
- Explains leader counting, ISR checks, rejected writes, retries, and durability trade-offs, stopping short of client implementation details.
- Examples
- Uses replication factor 3 with acks=all, contrasting the default threshold of 1 with min.insync.replicas=2.
- What you can do after
- Operate/configure Kafka topics to trade write availability for stronger durability and recognize insufficient-replica failures.
Read how Kafka Streams in Action, Second Edition explains min.insync.replicas →
Kafka for Architects
The minimum in-sync replicas setting is the configured number of synchronized partition replicas that must acknowledge a write for it to be considered successful.
- How it is used
- Protects Kafka write durability by requiring acknowledgments from a configured number of synchronized replicas.
- How deep it goes
- Defines ISR membership, write failure behavior, defaults, and the replication-factor trade-off without detailing broker internals.
- Examples
- Uses a three-broker Customer 360 deployment with replication factor 3 and min.insync.replicas set to 2.
- What you can do after
- Configure topic durability by pairing a replication factor with a minimum ISR appropriate to failure tolerance.
Read how Kafka for Architects explains min.insync.replicas →
Related concepts
- all acknowledgmentused by · All acknowledgment is a Kafka producer setting requiring confirmation from all in-sync replicas before a record write is considered successful.
- in-sync replicaconfigures · An in-sync replica is a Kafka partition replica sufficiently caught up with its leader to remain eligible for failover.
- high-water markconfigures · A high-water mark is a maximum observed value or configured threshold that bounds, tracks, or controls progress, storage, or processing.
- at-least-once deliveryconfigures · At-least-once delivery is a messaging or processing guarantee that each message or record is delivered or processed one or more times, so duplicates may occur.
- acknowledgment strategyconfigures · An acknowledgment strategy is a producer-side policy determining when a published message is acknowledged and what delivery guarantee applies.
- data lossaddresses · Data loss is the destruction, corruption, deletion, or unavailability of information that is expected to be retained or remain usable.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.