[
https://issues.apache.org/jira/browse/KAFKA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839234#comment-15839234
]
Ewen Cheslack-Postava commented on KAFKA-4680:
----------------------------------------------
I think it's totally reasonable to try to catch this much earlier -- if the
tools are allowing invalid configs in currently, it's simply a bug and we
should fix that behavior.
[~wushujames] You are marked as a contributor, so can self assign tickets. If
something is unassigned, no need to ask -- just claim it for yourself :)
> min.insync.replicas can be set higher than replication factor
> -------------------------------------------------------------
>
> Key: KAFKA-4680
> URL: https://issues.apache.org/jira/browse/KAFKA-4680
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.10.0.1
> Reporter: James Cheng
>
> It is possible to specify a min.insync.replicas for a topic that is higher
> than the replication factor of the topic. If you do this, you will not be
> able to produce to the topic with acks=all.
> Furthermore, each produce request (including retries) to the topic will emit
> an ERROR level message to the broker debuglogs. If this is not noticed
> quickly enough, it can cause the debuglogs to balloon.
> We actually hosed one of our Kafka clusters because of this. A topic got
> configured with min.insync.replicas > replication factor. It had partitions
> on all brokers of our cluster. The broker logs ballooned and filled up the
> disks. We run these clusters on CoreOS, and CoreOS's etcd database got
> corrupted. (Kafka didn't get corrupted, tho).
> I think Kafka should do validation when someone tries to change a topic to
> min.insync.replicas > replication factor, and reject the change.
> This would presumably affect kafka-topics.sh, kafka-configs.sh, as well as
> the CreateTopics operation that came in KIP-4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
