[
https://issues.apache.org/jira/browse/KAFKA-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16943275#comment-16943275
]
Guozhang Wang commented on KAFKA-8957:
--------------------------------------
I’d rather just document min.isr as minimum number of ISRs allowed when the
produce request with acks=all is received.
And the acknowledge mechanism just solely based on acks=all itself, have
nothing to do with the min.isr
> Improve docs about `min.isr` and `acks=all`
> -------------------------------------------
>
> Key: KAFKA-8957
> URL: https://issues.apache.org/jira/browse/KAFKA-8957
> Project: Kafka
> Issue Type: Improvement
> Components: clients, core
> Reporter: Matthias J. Sax
> Priority: Minor
>
> The current docs are as follows:
> {code:java}
> acks=all
> This means the leader will wait for the full set of in-sync replicas to
> acknowledge the record. This guarantees that the record will not be lost as
> long as at least one in-sync replica remains alive. This is the strongest
> available guarantee.{code}
> {code:java}
> min.in.sync.replicas
> When a producer sets acks to "all" (or -1), this configuration specifies the
> minimum number of replicas that must acknowledge a write for the write to be
> considered successful. If this minimum cannot be met, then the producer will
> raise an exception (either NotEnoughReplicas or
> NotEnoughReplicasAfterAppend). When used together, `min.insync.replicas` and
> `acks` allow you to enforce greater durability guarantees. A typical scenario
> would be to create a topic with a replication factor of 3, set
> min.insync.replicas to 2, and produce with acks of "all". This will ensure
> that the producer raises an exception if a majority of replicas do not
> receive a write.
> {code}
> The miss leading part seems to be:
>
> {noformat}
> the minimum number of replicas that must acknowledge the write
> {noformat}
> That could be interpreted to mean that the producer request can return
> *_before_* all replicas acknowledge the write. However, min.irs is a
> configuration that aims to specify how many replicase must be online, to
> consider a partition to be available.
> The actual behavior is the following (with replication factor = 3 and min.isr
> = 2)
> * If all three replicas are in-sync, brokers only ack to the producer after
> all three replicas got the data. (ie, both follows need to ack)
> * However, if one replicas lags (is not in-sync any longer), we are also ok
> to ack to the producer after the remaining in-sync follower acked.
> It's *_not_* the case, that if all three replicase are in-sync, brokers ack
> to the producer after one follower acked to the leader.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
