This is an automated email from the ASF dual-hosted git repository.
chia7712 pushed a commit to branch 4.0
in repository https://gitbox.apache.org/repos/asf/kafka.git
The following commit(s) were added to refs/heads/4.0 by this push:
new 44495e4ddef KAFKA-15583 doc update for the "strict min ISR" rule
(#18880)
44495e4ddef is described below
commit 44495e4ddef96d989e1909a353b070d59ebdbcd5
Author: Calvin Liu <[email protected]>
AuthorDate: Sat Feb 22 21:06:50 2025 -0800
KAFKA-15583 doc update for the "strict min ISR" rule (#18880)
Reviewers: Matthias J. Sax <[email protected]>, Dave Troiano
<[email protected]>, Chia-Ping Tsai <[email protected]>
---
docs/design.html | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/docs/design.html b/docs/design.html
index 466c4dfe7f4..a59a83b5bfb 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -382,11 +382,16 @@
<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.
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.
- 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
- 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,
- even if the number of in-sync replicas is lower than the minimum (e.g. it
can be as low as just the leader).
+ 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
acknowledgment is requested by the producer, then the message is committed
asynchronously across the set of in-sync replicas if
+ <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>
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>
