In-sync replicas (ISR) in Kafka - Commands & Configuration

Introduction

In Kafka, In-sync replicas (ISR) are the set of replicas that are fully caught up with the leader. They help keep data safe by ensuring copies of messages are stored on multiple brokers before confirming writes.

When you want to ensure no data loss if a broker fails by having multiple copies of data.

When you want to monitor which replicas are healthy and up-to-date with the leader.

When you want to configure how many replicas must confirm a write before it is considered successful.

When troubleshooting replication lag or broker failures in a Kafka cluster.

When tuning Kafka for high availability and durability of messages.

Commands

This command shows detailed information about the topic 'example-topic', including the leader, replicas, and the in-sync replicas (ISR). It helps verify which replicas are currently in sync.

Terminal

kafka-topics.sh --describe --topic example-topic --bootstrap-server localhost:9092

Expected Output

Topic: example-topic	PartitionCount: 1	ReplicationFactor: 3	Configs: 

	Topic: example-topic	Partition: 0	Leader: 1	Replicas: 1,2,3	Isr: 1,2,3

→

--describe - Shows detailed information about the topic.

→

--topic - Specifies the topic to describe.

→

--bootstrap-server - Specifies the Kafka server to connect to.

This command displays the configuration of the topic 'example-topic', including settings related to replication and ISR behavior.

Terminal

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name example-topic --describe

Expected Output

Configs for topic 'example-topic' are: 

min.insync.replicas=2

retention.ms=604800000

→

--entity-type topics - Specifies that the entity is a topic.

→

--entity-name example-topic - Specifies the topic name.

→

--describe - Shows the current configuration.

This command updates the topic 'example-topic' to require at least 2 replicas to be in sync before acknowledging writes, improving data durability.

Terminal

kafka-topics.sh --alter --topic example-topic --config min.insync.replicas=2 --bootstrap-server localhost:9092

Expected Output

No output (command runs silently)

→

--alter - Modifies the topic configuration.

→

--config min.insync.replicas=2 - Sets the minimum number of in-sync replicas required.

Verify the updated configuration and check the current ISR after the change.

Terminal

kafka-topics.sh --describe --topic example-topic --bootstrap-server localhost:9092

Expected Output

Topic: example-topic	PartitionCount: 1	ReplicationFactor: 3	Configs: min.insync.replicas=2

	Topic: example-topic	Partition: 0	Leader: 1	Replicas: 1,2,3	Isr: 1,2,3

→

--describe - Shows detailed topic information.

Key Concept

If you remember nothing else, remember: In-sync replicas are the copies of data that are fully caught up with the leader and ensure safe, durable writes.

Common Mistakes

Setting min.insync.replicas higher than the replication factor.

This causes Kafka to reject all writes because it can never meet the required number of in-sync replicas.

Set min.insync.replicas to a value less than or equal to the replication factor.

Ignoring ISR status and assuming all replicas are always in sync.

Leads to data loss risk if some replicas lag or fail without detection.

Regularly check ISR status with kafka-topics.sh --describe to monitor replica health.

Summary

Use kafka-topics.sh --describe to see the leader, replicas, and in-sync replicas of a topic.

Configure min.insync.replicas to control how many replicas must confirm writes for durability.

Monitor ISR to ensure replicas are healthy and data is safely replicated.