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)

Reply via email to