skip to content

Where is min.insync.replicas configured, and how do you set up the full durability contract for a topic in practice?

level: middleimportance: should knowfreq 45%

answer

  1. RF at create-time (or reassignment), not a dynamic config
  2. min.insync.replicas: broker default + per-topic override, dynamic
  3. acks owned by producer, default acks=all since 3.0
  4. kafka-configs --alter to change floor on live topic
  5. common bug: min.isr=2 but producer still acks=1

basics

~10 s

min.insync.replicas is a broker default that can be overridden per topic. The full contract needs three parts: replication factor at topic creation, min.insync.replicas as a topic config, and acks=all on the producer.

solid answer

~40 s

min.insync.replicas can be set cluster-wide in server.properties and overridden per topic via a topic-level config. The durability contract has three independently-owned pieces: (1) replication.factor, fixed at topic creation (or changed later with kafka-reassign-partitions); (2) min.insync.replicas, a dynamic topic config you can change with kafka-configs --alter; and (3) acks=all, set by the producer application. Forgetting any one breaks durability — most commonly teams set min.insync.replicas on the topic but leave producers at the default acks (acks=all is the default since Kafka 3.0, but older or explicitly-set clients may use acks=1). You typically create the topic with --replication-factor 3 and --config min.insync.replicas=2, and ensure producers use acks=all. Because min.insync.replicas is a per-topic override of a broker default, you can keep a strict default and relax it for low-value topics, or vice versa.

go deeper

for a junior

Know the three pieces: replication factor, min.insync.replicas, acks=all.

for a middle

Know which are broker-default vs topic-override vs producer-owned, and the CLI to set them.

for a senior

Explain dynamic reconfiguration, cluster default strategy, and how to audit the effective contract.

for a principal

Define org-wide topic provisioning policy and guardrails so durability isn't left to individual teams.

## Three settings, three owners The durability contract is not a single switch. It is assembled from three configs, each owned and changed differently: 1. **`replication.factor`** — the number of copies. Set at **topic creation** (`--replication-factor 3`). It is *not* a mutable topic config; to change it later you run a **partition reassignment** (`kafka-reassign-partitions.sh`) to add/remove replicas. RF is the ceiling on the ISR. 2. **`min.insync.replicas`** — the ISR floor. It has a **broker-level default** (in `server.properties`, default 1) and a **per-topic override**. It is a *dynamic* config: change it on a live topic with `kafka-configs.sh --alter --add-config min.insync.replicas=2`. 3. **`acks`** — owned by the **producer application**, not the broker. Default is `acks=all` since Kafka 3.0 (`enable.idempotence=true` became default and forces `acks=all`); older clients or explicit settings may use `acks=1`. ## Creating a durable topic ``` kafka-topics.sh --create --topic orders \ --replication-factor 3 --partitions 6 \ --config min.insync.replicas=2 --bootstrap-server broker:9092 ``` Then the producer side: ``` acks=all ``` ## Broker default vs topic override Because `min.insync.replicas` is a broker default *with* a per-topic override, you have flexibility: - Set a **safe cluster default** of 2 so new topics are durable by default, and override to 1 for explicitly low-value/high-throughput topics. - Or keep the broker default at 1 (the Kafka default) and explicitly set 2 on important topics. Use `kafka-configs.sh --describe --entity-type topics --entity-name orders` to see the effective value and whether it's a topic override or inherited broker default. ## The common failure mode The most frequent real-world mistake: a team sets `min.insync.replicas=2` on the topic, congratulates themselves on durability, but their producers still send with `acks=1` (perhaps an older client or an explicit override). Because the floor is **ignored** unless `acks=all`, they get **leader-only durability** and the floor does nothing. Always verify all three settings together. Conversely, setting `acks=all` with a broker/topic `min.insync.replicas=1` is also weak — 'all' can mean just the leader. ## Internal topics Kafka's own `__consumer_offsets` and `__transaction_state` topics ship with high RF (default 3) and `min.insync.replicas` defaults appropriate to durability, configurable via `offsets.topic.replication.factor` and related broker settings — a reminder that the same contract applies to internal state.

  • Can you change min.insync.replicas on a running topic without downtime?
    Yes — it's a dynamic per-topic config. Use kafka-configs.sh --alter --add-config min.insync.replicas=2. It takes effect immediately for new produce requests; no restart needed.
  • Can you increase the replication factor the same way?
    No. replication.factor is not a mutable topic config — you set it at creation. To change it on an existing topic you run a partition reassignment (kafka-reassign-partitions.sh) that adds the new replica brokers.

saying these in an interview costs you the question

  • Saying replication.factor is a dynamic config like min.insync.replicas (it requires reassignment to change).
  • Believing setting min.insync.replicas alone makes a topic durable without also setting acks=all on producers.
  • Thinking acks is a broker/topic config — it is owned by the producer.
  • Assuming the broker default min.insync.replicas is 2 (the Kafka default is 1).

context

resolving links…