[
https://issues.apache.org/jira/browse/KAFKA-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832729#comment-15832729
]
huxi commented on KAFKA-4680:
-----------------------------
If sending records to a topic with a larger 'min.insync.replicas' than
replication factor with acks set to all, client callback returns
`NOT_ENOUGH_REPLICAS` indicating that you be aware of this and adjust the
topic-level min.isr.replicas or check the broker availability, doesn't it?
I do agree that it's definitely better if we add some check before
creating/altering topic. What I am concerned is the completeness. If a check is
introduced during creating/altering topics, then do we also need to add some
checks before changing the replication factor, especially reducing this number
(we could call kafka-reassign-partitions.sh to do this although it's sort of
inconvenient to use), to ensure the reduced number is still larger than
min.isr.replicas? If this is the case, seems we have to figure out all the
affected function paths.
You of course could assign this jira to youself and get rolling :-)
> 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)
