root
/
kafka
mirror of https://github.com/apache/kafka.git
1
0
Fork 0
Code Issues Actions 3 Packages Projects Releases Wiki Activity

KAFKA-15583 doc update for the "strict min ISR" rule (#18880) 

Reviewers: Matthias J. Sax <matthias@confluent.io>, Dave Troiano <dtroiano@confluent.io>, Chia-Ping Tsai <chia7712@gmail.com>
This commit is contained in:
Calvin Liu 2025-02-22 21:06:50 -08:00 committed by GitHub
parent 13cb87c2d0
commit a1372ced69
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/design.html
View File

@ -382,11 +382,16 @@
<p> <p>
We can now more precisely define that a message is considered committed when all replicas in the ISR for that partition have applied it to their log. We can now more precisely define that a message is considered committed when all replicas in the ISR for that partition have applied it to their log.
Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand, Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand,
have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the <code>acks</code> setting that the
producer uses. producer uses.
Note that topics have a setting for the "minimum number" of in-sync replicas that is checked when the producer requests acknowledgment that a message Note that topics have a setting for the minimum number of in-sync replicas (<code>min.insync.replicas</code>) that is checked when the producer requests acknowledgment that a message
has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed, has been written to the full set of in-sync replicas. If a less stringent acknowledgment is requested by the producer, then the message is committed asynchronously across the set of in-sync replicas if
even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader). <code>acks=0</code>, or synchronously only on the leader if <code>acks=1</code>.
Regardless of the <code>acks</code> setting, the messages will not be visible to the consumers until all the following conditions are met:
<ol>
<li>The messages are replicated to all the in-sync replicas.</li>
<li>The number of the in-sync replicas is no less than the <code>min.insync.replicas</code> setting.</li>
</ol>
<p> <p>
The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times. The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times.
<p> <p>