In-sync replica

As explained in Kafka for Architects

An in-sync replica is a Kafka partition replica that has caught up with its leader and is not substantially lagging.

An in-sync replica (ISR) is a Kafka partition replica that has caught up with its leader and is not substantially lagging. Replicas pull new records asynchronously, so followers can temporarily contain less data than the leader. The ISR identifies the replicas currently eligible to support reliable writes and leader failover. section 2.3.1

The ISR connects replication health to write behavior. With acks=all, a producer can receive success only after records are replicated to all in-sync replicas. The min.insync.replicas setting requires a minimum ISR count; if the count falls below it, producers receive an exception rather than accepting a potentially unsafe write. section 2.3.1 section 2.3.2

Use ISR configuration to make an explicit durability–availability trade-off:

• Favor durability by maintaining multiple replicas, requiring acknowledgments from all ISRs, and tolerating downtime when too few remain. section 11.3.2
• Favor availability by allowing producers to continue with fewer acknowledgments, accepting that a failure may lose some messages. section 11.3.2
• Treat broker failure or overload as an operational ISR risk because replication delays can remove replicas from the in-sync set. section 2.3.2

A resilient partition configuration

A replication factor of 3 with min.insync.replicas set to 2 keeps a partition writable after one broker fails, provided two replicas remain caught up. If fewer than two ISRs remain, writes fail instead of weakening the durability guarantee. section 2.3.2

Figure 2.10 Each partition has one replica designated as the leader, while the others serve as followers.

Use the partition diagram to distinguish the leader from follower replicas and understand where ISR membership applies. section 2.3.1

Table 11.2 Balancing durability and availability

Configuration setting	Improve durability	Improve availability	Setting type
acks	Use acks=all to ensure data is written to all in-sync replicas	With acks=1 or 0 the producer can continue sending data even if some replicas are temporarily unavailable	Producer
enable.idempotence	Enable to avoid duplicate messages and improve reliability	Enable to avoid duplicate messages and retries in the producer	Producer
enable.auto.commit	Disable and manually commit offsets after processing to avoid data loss	Consumer progresses without waiting for manual commit logic to complete	Consumer
isolation.level	Set to read_committed to read only committed data	Set to read_uncommitted to allow faster reads of all data	Consumer
max.poll.records	Smaller batches reduce memory pressure and risk of data loss during failure	Larger batches improve consumer throughput and avoid stalling (but may risk larger reprocesses)	Consumer
max.poll.interval.ms	Reduce to catch slow consumers faster and avoid stale offsets	Increase to allow slower consumers to stay in group longer	Consumer
session.timeout.ms	Reduce to detect dead consumers quickly and maintain ISRs	May be increased to avoid unnecessary rebalances, but for detecting dead consumers it can be decreased	Consumer
replication.factor	Use a higher replication factor for better data redundancy	A lower replication factor can speed up recovery but risks data loss	Broker
min.insync.replicas	Set higher to ensure more replicas are in sync before committing data	Set lower to allow writes even with fewer in-sync replicas	Broker
unclean.leader .election.enable	Disable to avoid data loss with unclean leader election	Enable to allow faster leader election even if some data is lost	Broker
broker.rack	Distribute replicas across racks to avoid rack failures causing data loss	Ensure rack awareness for faster recovery if a rack fails	Broker
log.flush.interval .messages	Reduce to flush data more frequently to disk, minimizing potential data loss	Increase to flush data less frequently for faster throughput	Broker
log.flush.interval.ms	Reduce to flush data to disk more frequently	Increase to flush less often and improve broker throughput	Broker
num.recovery.threads .per.data.dir	Increase to reduce the window in which durability is weakened	Increase to speed up broker recovery after a crash	Broker
num.standby .replicas	Increase to reduce the risk of data loss during failover	Increase to maintain availability during maintenance or failures	Broker
replica.lag.time .max.ms	Reduce to quickly detect lagging replicas and exclude them from ISRs for consistency	Increase to tolerate more lag and avoid unnecessary ISR changes that can affect availability	Broker
auto.leader .rebalance.enable	Disable to keep leaders stable, avoiding leader changes that can affect data consistency	Enable to allow automatic rebalancing of leaders, improving availability during broker failures	Broker

Use the configuration table to compare durability- and availability-oriented choices for acknowledgments, idempotence, offset commits, isolation, and batch size. section 11.3.2

How Kafka for Architects covers it

How deep it goes

Defines ISR membership and explains configuration consequences, but defers deeper client-application behavior and replication internals.

Examples

Uses a replication factor of 3 with min.insync.replicas set to 2, plus durability- and availability-oriented Kafka settings.

What it assumes

Assumes Kafka partitions and replicas, while defining leaders, followers, lag, and minimum in-sync replica requirements.

What you can do after

Operate/configure Kafka replication by selecting ISR thresholds and acknowledgment behavior for resilience or uptime.

How it connects

Ties in-sync replicas to partition leaders, followers, replication factor, producer acknowledgments, failover, and data durability.

liveBookmanning.com

Read Kafka for Architects on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Apache Kafka in ActionAn in-sync replica is a Kafka partition replica whose data is up to date with the leader.
• 

  liveBookmanning.com
  Kafka Streams in Action, Second EditionAn in-sync replica set is the set of Kafka partition replicas that are sufficiently caught up with the partition leader to remain eligible for failover.

Compare how 3 books explain in-sync replica →

Related concepts

• acknowledgment strategyused by · An acknowledgment strategy is a producer-side policy determining when a published message is acknowledged and what delivery guarantee applies.
• replicakind of · A replica is a copy of data or state, or an equivalent running instance of a component, maintained alongside others in a replicated system.
• controllerused by · A Kafka controller is a server role that manages cluster metadata and coordinates partition, replica, and leader state.
• all acknowledgmentused by · All acknowledgment is a Kafka producer setting requiring confirmation from all in-sync replicas before a record write is considered successful.
• min.insync.replicasconfigured by · min.insync.replicas is a Kafka setting specifying the minimum number of in-sync replicas that must acknowledge a write for it to succeed.
• primary nodeused by · A primary node is a designated authoritative or coordinating member of a distributed system, typically responsible for accepting operations or coordinating replicated state.

This explainer was generated by Manning's knowledge graph from the text of Kafka for Architects. The section links point to the parts of the book it draws on.