You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -155,7 +157,7 @@ <h4><a class="toc-backref" href="#id4">application.id</a><a class="headerlink" h
155
157
<divclass="section"id="bootstrap-servers">
156
158
<h4><aclass="toc-backref"href="#id5">bootstrap.servers</a><aclass="headerlink"href="#bootstrap-servers"title="Permalink to this headline"></a></h4>
157
159
<blockquote>
158
-
<div><p>(Required) The Kafka bootstrap servers. This is the same <aclass="reference external"href="http://kafka.apache.org/documentation.html#producerconfigs">setting</a> that is used by the underlying producer and consumer clients to connect to the Kafka cluster.
160
+
<div><p>(Required) The Kafka bootstrap servers. This is the same <aclass="reference external"href="/{{version}}/documentation.html#producerconfigs">setting</a> that is used by the underlying producer and consumer clients to connect to the Kafka cluster.
<p>Increasing the replication factor to 3 ensures that the internal Kafka Streams topic can tolerate up to 2 broker failures. Changing the acks setting to “all”
198
-
guarantees that a record will not be lost as long as one replica is alive. The tradeoff from moving to the default values to the recommended ones is
203
+
<p>Increasing the replication factor to 3 ensures that the internal Kafka Streams topic can tolerate up to 2 broker failures.
204
+
The tradeoff from moving to the default values to the recommended ones is
199
205
that some performance and more storage space (3x with the replication factor of 3) are sacrificed for more resiliency.</p>
200
-
<divclass="section"id="acks">
206
+
<divclass="section"id="acks-short">
201
207
<h4><aclass="toc-backref"href="#id22">acks</a><aclass="headerlink"href="#acks"title="Permalink to this headline"></a></h4>
202
208
<blockquote>
203
209
<div><p>The number of acknowledgments that the leader must have received before considering a request complete. This controls
204
210
the durability of records that are sent. The possible values are:</p>
205
211
<ulclass="simple">
206
-
<li><codeclass="docutils literal"><spanclass="pre">acks=0</span></code> The producer does not wait for acknowledgment from the server and the record is immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the producer won’t generally know of any failures. The offset returned for each record will always be set to <codeclass="docutils literal"><spanclass="pre">-1</span></code>.</li>
207
-
<li><codeclass="docutils literal"><spanclass="pre">acks=1</span></code> The leader writes the record to its local log and responds without waiting for full acknowledgement from all followers. If the leader immediately fails after acknowledging the record, but before the followers have replicated it, then the record will be lost.</li>
208
-
<li><codeclass="docutils literal"><spanclass="pre">acks=all</span></code> The leader waits for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost if there is at least one in-sync replica alive. This is the strongest available guarantee.</li>
212
+
<li><codeclass="docutils literal"><spanclass="pre">acks="0"</span></code> The producer does not wait for acknowledgment from the server and the record is immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the producer won’t generally know of any failures. The offset returned for each record will always be set to <codeclass="docutils literal"><spanclass="pre">-1</span></code>.</li>
213
+
<li><codeclass="docutils literal"><spanclass="pre">acks="1"</span></code> The leader writes the record to its local log and responds without waiting for full acknowledgement from all followers. If the leader immediately fails after acknowledging the record, but before the followers have replicated it, then the record will be lost.</li>
214
+
<li><codeclass="docutils literal"><spanclass="pre">acks="all"</span></code> (default since 3.0 release) The leader waits for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost if there is at least one in-sync replica alive. This is the strongest available guarantee.</li>
209
215
</ul>
210
216
<p>For more information, see the <aclass="reference external"href="https://kafka.apache.org/documentation/#producerconfigs">Kafka Producer documentation</a>.</p>
211
217
</div></blockquote>
212
218
</div>
213
-
<divclass="section"id="id2">
214
-
<h4><aclass="toc-backref"href="#id23">replication.factor</a><aclass="headerlink"href="#id2"title="Permalink to this headline"></a></h4>
219
+
<divclass="section"id="replication-factor-short">
220
+
<h4><aclass="toc-backref"href="#id23">replication.factor</a><aclass="headerlink"href="#id23"title="Permalink to this headline"></a></h4>
215
221
<blockquote>
216
222
<div>See the <aclass="reference internal"href="#replication-factor-parm"><spanclass="std std-ref">description here</span></a>.</div></blockquote>
217
223
</div>
218
-
<divclass="section"id="i32">
219
-
<h4><aclass="toc-backref"href="#id23">num.standby.replicas</a><aclass="headerlink"href="#id2"title="Permalink to this headline"></a></h4>
224
+
<divclass="section"id="min-isr-short">
225
+
<h4><aclass="toc-backref"href="#id44">min.insync.replicas</a><aclass="headerlink"href="#id44"title="Permalink to this headline"></a></h4>
226
+
<p>The minimum number of in-sync replicas available for replication if the producer is configured with <code>acks="all"</code>
227
+
(see <ahref="/{{version}}/documentation/#topicconfigs_min.insync.replicas">topic configs</a>).
for the reassigned warmups to restore sufficient state for them to be transitioned to active tasks. Must be at least 1.
921
934
</p>
922
935
<p>
923
-
Note that one warmup replica corresponds to one <ahref="https://kafka.apache.org/34/documentation/streams/architecture#streams_architecture_tasks">Stream Task</a>. Furthermore, note that each warmup task can only be promoted to an active task during
936
+
Note that one warmup replica corresponds to one <ahref="/{{version}}/documentation/streams/architecture#streams_architecture_tasks">Stream Task</a>. Furthermore, note that each warmup task can only be promoted to an active task during
924
937
a rebalance (normally during a so-called probing rebalance, which occur at a frequency specified by the
925
938
<codeclass="docutils literal"><spanclass="pre">probing.rebalance.interval.ms</span></code> config). This means that the
926
939
maximum rate at which active tasks can be migrated from one Kafka Streams instance to another instance can be determined by
0 commit comments