[jira] [Created] (KAFKA-8957) Improve docs about `min.isr.` and `acks=all`

["Matthias J. Sax (Jira)" <ji...@apache.org>]

Matthias J. Sax created KAFKA-8957:
--------------------------------------

             Summary: 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


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)