Answer
Kafka intentionally permits creating a topic whose replication factor is lower than the effective min.insync.replicas. The mismatch is not rejected at creation time; it surfaces as a NOT_ENOUGH_REPLICAS error when a producer uses acks=all and the in-sync replica (ISR) count cannot satisfy the threshold. This behavior is by design, not an oversight.
Why creation-time validation is absent
The separation exists because min.insync.replicas is primarily a broker-level durability control, while replication factor is a topic-level layout property. Operators sometimes pre-configure a higher durability floor and later expand replicas through partition reassignment. Creation-time rejection would block that workflow and would also prevent temporary ISR shrinkage during maintenance. The producer-side ISR check remains the enforcement point.
Auditing after KRaft migration
KRaft migration moves metadata from ZooKeeper into the KRaft metadata log, but it does not introduce new consistency checks between replication factor and min.insync.replicas. If broker defaults or topic overrides were carried over incorrectly, the same runtime failure mode persists.
To audit, compare the effective min.insync.replicas for each topic against its replication factor. Use kafka-configs.sh to inspect both broker and topic entities:
kafka-configs.sh --bootstrap-server <broker> --entity-type brokers --entity-name <id> --describe
kafka-configs.sh --bootstrap-server <broker> --entity-type topics --entity-name <topic> --describe
For programmatic checks, AdminClient.describeTopics returns replication factor, and AdminClient.describeConfigs on topic resources returns the effective configuration. Flag any topic where min.insync.replicas exceeds replication factor and that requires acks=all.
Reconciliation steps
- Identify the effective
min.insync.replicas for each topic, distinguishing broker defaults from topic overrides. Topic-level overrides depend on the Kafka version and distribution, so verify the release's supported topic configuration list before assuming an override exists.
- For topics that must accept
acks=all writes, ensure min.insync.replicas is less than or equal to the replication factor. Adjust either the broker default or the topic override.
- If raising replication factor, perform the reassignment before or alongside lowering the effective threshold to avoid transient
NOT_ENOUGH_REPLICAS errors. Reassignment itself can temporarily shrink ISR.
Assumptions and uncertainty
This guidance assumes a standard Apache Kafka distribution. Some managed or vendor distributions may expose additional validation or different default inheritance. Confirm the effective value resolved for each topic rather than assuming the broker default applies uniformly.
Verification
To confirm the behavior in your environment, create a test topic with replication factor 1 on a broker whose effective min.insync.replicas is 2, produce with acks=all, and observe the NOT_ENOUGH_REPLICAS error. This validates that the runtime check is active before you change production settings.
apachekafka