You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@kafka.apache.org by da...@apache.org on 2025/12/22 01:14:11 UTC
(kafka) branch 4.2 updated: KAFKA-20013 Markdown docs for 4.2.x (#21194)
This is an automated email from the ASF dual-hosted git repository.
davidarthur pushed a commit to branch 4.2
in repository https://gitbox.apache.org/repos/asf/kafka.git
The following commit(s) were added to refs/heads/4.2 by this push:
new 8d347ad6035 KAFKA-20013 Markdown docs for 4.2.x (#21194)
8d347ad6035 is described below
commit 8d347ad6035c5cb305ad7cc1d8206363d84b6853
Author: Harish Vishwanath <ha...@gmail.com>
AuthorDate: Sun Dec 21 17:14:04 2025 -0800
KAFKA-20013 Markdown docs for 4.2.x (#21194)
Convert HTML docs to Markdown for 4.2
Reviewers: David Arthur <mu...@gmail.com>
---
docs/README.md | 4 -
docs/{documentation/index.html => _index.md} | 12 +-
docs/api.html | 125 -
docs/apis/_index.md | 133 +
docs/compatibility-summary.html | 27 -
docs/configuration.html | 471 --
.../core-concepts.html => configuration/_index.md} | 13 +-
.../index.html => configuration/admin-configs.md} | 13 +-
docs/configuration/broker-configs.md | 186 +
docs/configuration/configuration-providers.md | 157 +
.../consumer-configs.md} | 13 +-
.../index.html => configuration/group-configs.md} | 13 +-
.../kafka-connect-configs.md} | 28 +-
.../kafka-streams-configs.md} | 13 +-
docs/configuration/mirrormaker-configs.md | 45 +
.../producer-configs.md} | 13 +-
docs/configuration/system-properties.md | 183 +
docs/configuration/tiered-storage-configs.md | 51 +
docs/configuration/topic-configs.md | 52 +
docs/connect.html | 1060 ---
docs/design.html | 766 ---
.../streams/index.html => design/_index.md} | 13 +-
docs/design/design.md | 507 ++
docs/design/protocol.md | 217 +
docs/docker.html | 58 -
docs/documentation.html | 124 -
docs/documentation/{index.html => _index.md} | 10 +-
docs/documentation/compatibility.html | 201 -
.../datatypes.html => legacy-redirect.md} | 12 +-
.../streams/{tutorial.html => _index.md} | 11 +-
.../streams/{quickstart.html => architecture.md} | 11 +-
.../{index.html => streams/core-concepts.md} | 10 +-
.../developer-guide/_index.md} | 10 +-
.../developer-guide/app-reset-tool.md} | 10 +-
.../streams/developer-guide/config-streams.html | 19 -
.../developer-guide/config-streams.md} | 10 +-
.../developer-guide/datatypes.md} | 10 +-
.../streams/developer-guide/dsl-api.html | 19 -
.../developer-guide/dsl-api.md} | 10 +-
.../developer-guide/dsl-topology-naming.html | 19 -
.../developer-guide/dsl-topology-naming.md} | 10 +-
.../streams/developer-guide/index.html | 19 -
.../developer-guide/interactive-queries.html | 19 -
.../developer-guide/interactive-queries.md} | 10 +-
.../developer-guide/kafka-streams-group-sh.html | 19 -
.../streams/developer-guide/manage-topics.html | 19 -
.../developer-guide/manage-topics.md} | 10 +-
.../streams/developer-guide/memory-mgmt.html | 19 -
.../developer-guide/memory-mgmt.md} | 10 +-
.../streams/developer-guide/processor-api.html | 19 -
.../developer-guide/processor-api.md} | 10 +-
.../streams/developer-guide/running-app.html | 19 -
.../developer-guide/running-app.md} | 10 +-
.../streams/developer-guide/security.html | 19 -
.../developer-guide/security.md} | 10 +-
.../streams/developer-guide/testing.html | 19 -
.../developer-guide/testing.md} | 10 +-
.../developer-guide/write-streams-app.md} | 10 +-
.../streams/developer-guide/write-streams.html | 19 -
.../{index.html => streams/introduction.md} | 10 +-
.../{index.html => streams/quickstart.md} | 10 +-
.../{index.html => streams/tutorial.md} | 10 +-
docs/documentation/streams/upgrade-guide.html | 19 -
.../{index.html => streams/upgrade-guide.md} | 10 +-
docs/documentation/zk2kraft.html | 320 -
.../index.html => getting-started/_index.md} | 12 +-
docs/getting-started/compatibility.md | 428 ++
docs/getting-started/docker.md | 70 +
.../ecosystem.md} | 13 +-
docs/getting-started/introduction.md | 110 +
docs/getting-started/quickstart.md | 228 +
docs/getting-started/upgrade.md | 256 +
docs/getting-started/uses.md | 63 +
docs/getting-started/zk2kraft.md | 237 +
docs/implementation.html | 205 -
.../index.html => implementation/_index.md} | 12 +-
docs/implementation/distribution.md | 35 +
docs/implementation/log.md | 77 +
docs/implementation/message-format.md | 115 +
docs/implementation/messages.md | 29 +
docs/implementation/network-layer.md | 29 +
docs/introduction.html | 220 -
docs/js/templateData.js | 24 -
.../architecture.html => kafka-connect/_index.md} | 13 +-
docs/kafka-connect/administration.md | 76 +
docs/kafka-connect/connector-development-guide.md | 412 ++
docs/kafka-connect/overview.md | 40 +
docs/kafka-connect/user-guide.md | 715 ++
.../index.html => operations/_index.md} | 12 +-
docs/operations/basic-kafka-operations.md | 652 ++
docs/operations/consumer-rebalance-protocol.md | 86 +
docs/operations/datacenters.md | 39 +
docs/operations/eligible-leader-replicas.md | 58 +
...o-replication-(cross-cluster-data-mirroring).md | 465 ++
docs/operations/hardware-and-os.md | 150 +
docs/operations/java-version.md | 47 +
docs/operations/kraft.md | 275 +
docs/operations/monitoring.md | 7105 ++++++++++++++++++++
docs/operations/multi-tenancy.md | 133 +
docs/operations/tiered-storage.md | 168 +
docs/operations/transaction-protocol.md | 54 +
docs/ops.html | 4938 --------------
docs/protocol.html | 239 -
docs/quickstart.html | 354 -
docs/security.html | 2494 -------
.../index.html => security/_index.md} | 12 +-
docs/security/authentication-using-sasl.md | 712 ++
docs/security/authorization-and-acls.md | 2706 ++++++++
.../encryption-and-authentication-using-ssl.md | 304 +
...ating-security-features-in-a-running-cluster.md | 90 +
docs/security/listener-configuration.md | 96 +
docs/security/security-overview.md | 40 +
.../index.html => streams/_index.md} | 12 +-
docs/streams/architecture.html | 206 -
docs/streams/architecture.md | 99 +
docs/streams/core-concepts.html | 387 --
docs/streams/core-concepts.md | 176 +
.../developer-guide/_index.md} | 13 +-
docs/streams/developer-guide/app-reset-tool.html | 187 -
docs/streams/developer-guide/app-reset-tool.md | 143 +
docs/streams/developer-guide/config-streams.html | 1519 -----
docs/streams/developer-guide/config-streams.md | 1941 ++++++
docs/streams/developer-guide/datatypes.html | 309 -
docs/streams/developer-guide/datatypes.md | 317 +
docs/streams/developer-guide/dsl-api.html | 4390 ------------
docs/streams/developer-guide/dsl-api.md | 5932 ++++++++++++++++
.../developer-guide/dsl-topology-naming.html | 363 -
.../streams/developer-guide/dsl-topology-naming.md | 269 +
docs/streams/developer-guide/index.html | 103 -
.../developer-guide/interactive-queries.html | 503 --
.../streams/developer-guide/interactive-queries.md | 496 ++
.../developer-guide/kafka-streams-group-sh.html | 278 -
docs/streams/developer-guide/manage-topics.html | 135 -
docs/streams/developer-guide/manage-topics.md | 77 +
docs/streams/developer-guide/memory-mgmt.html | 280 -
docs/streams/developer-guide/memory-mgmt.md | 204 +
docs/streams/developer-guide/processor-api.html | 628 --
docs/streams/developer-guide/processor-api.md | 418 ++
docs/streams/developer-guide/running-app.html | 206 -
docs/streams/developer-guide/running-app.md | 116 +
docs/streams/developer-guide/security.html | 249 -
docs/streams/developer-guide/security.md | 222 +
docs/streams/developer-guide/testing.html | 396 --
docs/streams/developer-guide/testing.md | 329 +
docs/streams/developer-guide/write-streams-app.md | 218 +
docs/streams/developer-guide/write-streams.html | 224 -
docs/streams/index.html | 355 -
docs/streams/introduction.md | 172 +
docs/streams/quickstart.html | 358 -
docs/streams/quickstart.md | 261 +
docs/streams/tutorial.html | 608 --
docs/streams/tutorial.md | 464 ++
docs/streams/upgrade-guide.html | 1239 ----
docs/streams/upgrade-guide.md | 562 ++
docs/toc.html | 243 -
docs/upgrade.html | 729 --
docs/uses.html | 81 -
157 files changed, 30456 insertions(+), 25927 deletions(-)
diff --git a/docs/README.md b/docs/README.md
deleted file mode 100644
index a71c49a57b1..00000000000
--- a/docs/README.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Docs
-
-The documentation needs to run with [kafka-site](https://github.com/apache/kafka-site).
-Please check the README in the kafka-site repository to preview documentation locally.
diff --git a/docs/documentation/index.html b/docs/_index.md
similarity index 85%
copy from docs/documentation/index.html
copy to docs/_index.md
index 1d7507f30a9..a1527c1947b 100644
--- a/docs/documentation/index.html
+++ b/docs/_index.md
@@ -1,3 +1,13 @@
+---
+title: AK 4.2.X
+description: Documentation for AK 4.2.X
+weight:
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,4 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
diff --git a/docs/api.html b/docs/api.html
deleted file mode 100644
index 992c1085c90..00000000000
--- a/docs/api.html
+++ /dev/null
@@ -1,125 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-<script id="api-template" type="text/x-handlebars-template">
- Kafka includes six core apis:
- <ol>
- <li>The <a href="#producerapi">Producer</a> API allows applications to send streams of data to topics in the Kafka cluster.
- <li>The <a href="#consumerapi">Consumer</a> API allows applications to read streams of data from topics in the Kafka cluster.
- <li>The <a href="#shareconsumerapi">Share consumer</a> API allows applications in a share group to cooperatively consume and process data from Kafka topics.
- <li>The <a href="#streamsapi">Streams</a> API allows transforming streams of data from input topics to output topics.
- <li>The <a href="#connectapi">Connect</a> API allows implementing connectors that continually pull from some source system or application into Kafka or push from Kafka into some sink system or application.
- <li>The <a href="#adminapi">Admin</a> API allows managing and inspecting topics, brokers, and other Kafka objects.
- </ol>
-
- Kafka exposes all its functionality over a language-independent protocol which has clients available in many programming languages. However only the Java clients are maintained as part of the main Kafka project, the others are available as independent open source projects. A list of non-Java clients is available <a href="https://cwiki.apache.org/confluence/x/3gDVAQ">here</a>.
-
- <h3 class="anchor-heading"><a id="producerapi" class="anchor-link"></a><a href="#producerapi">2.1 Producer API</a></h3>
-
- The Producer API allows applications to send streams of data to topics in the Kafka cluster.
- <p>
- Examples of using the producer are shown in the
- <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/producer/KafkaProducer.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>.
- <p>
- To use the producer, add the following Maven dependency to your project:
-
- <pre class="line-numbers"><code class="language-xml"><dependency>
- <groupId>org.apache.kafka</groupId>
- <artifactId>kafka-clients</artifactId>
- <version>{{fullDotVersion}}</version>
-</dependency></code></pre>
-
- <h3 class="anchor-heading"><a id="consumerapi" class="anchor-link"></a><a href="#consumerapi">2.2 Consumer API</a></h3>
-
- The Consumer API allows applications to read streams of data from topics in the Kafka cluster.
- <p>
- Examples of using the consumer are shown in the
- <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>.
- <p>
- To use the consumer, add the following Maven dependency to your project:
- <pre class="line-numbers"><code class="language-xml"><dependency>
- <groupId>org.apache.kafka</groupId>
- <artifactId>kafka-clients</artifactId>
- <version>{{fullDotVersion}}</version>
-</dependency></code></pre>
-
- <h3 class="anchor-heading"><a id="shareconsumerapi" class="anchor-link"></a><a href="#shareconsumerapi">2.3 Share Consumer API</a></h3>
-
- The Share Consumer API enables applications in a share group to cooperatively consume and process data from Kafka topics.
- <p>
- Examples of using the share consumer are shown in the
- <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaShareConsumer.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>.
- <p>
- To use the share consumer, add the following Maven dependency to your project:
- <pre class="line-numbers"><code class="language-xml"><dependency>
- <groupId>org.apache.kafka</groupId>
- <artifactId>kafka-clients</artifactId>
- <version>{{fullDotVersion}}</version>
-</dependency></code></pre>
-
- <h3 class="anchor-heading"><a id="streamsapi" class="anchor-link"></a><a href="#streamsapi">2.4 Streams API</a></h3>
-
- The <a href="/{{version}}/documentation/streams">Streams</a> API allows transforming streams of data from input topics to output topics.
- <p>
- Examples of using this library are shown in the
- <a href="/{{version}}/javadoc/index.html?org/apache/kafka/streams/KafkaStreams.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>.
- <p>
- Additional documentation on using the Streams API is available <a href="/{{version}}/documentation/streams">here</a>.
- <p>
- To use Kafka Streams, add the following Maven dependency to your project:
-
- <pre class="line-numbers"><code class="language-xml"><dependency>
- <groupId>org.apache.kafka</groupId>
- <artifactId>kafka-streams</artifactId>
- <version>{{fullDotVersion}}</version>
-</dependency></code></pre>
-
- <p>
- When using Scala you may optionally include the <code>kafka-streams-scala</code> library. Additional documentation on using the Kafka Streams DSL for Scala is available <a href="/{{version}}/documentation/streams/developer-guide/dsl-api.html#scala-dsl">in the developer guide</a>.
- <p>
- To use Kafka Streams DSL for Scala {{scalaVersion}}, add the following Maven dependency to your project:
-
- <pre class="line-numbers"><code class="language-xml"><dependency>
- <groupId>org.apache.kafka</groupId>
- <artifactId>kafka-streams-scala_{{scalaVersion}}</artifactId>
- <version>{{fullDotVersion}}</version>
-</dependency></code></pre>
-
- <h3 class="anchor-heading"><a id="connectapi" class="anchor-link"></a><a href="#connectapi">2.5 Connect API</a></h3>
-
- The Connect API allows implementing connectors that continually pull from some source data system into Kafka or push from Kafka into some sink data system.
- <p>
- Many users of Connect won't need to use this API directly, though, they can use pre-built connectors without needing to write any code. Additional information on using Connect is available <a href="/documentation.html#connect">here</a>.
- <p>
- Those who want to implement custom connectors can see the <a href="/{{version}}/javadoc/index.html?org/apache/kafka/connect" title="Kafka {{dotVersion}} Javadoc">javadoc</a>.
- <p>
-
- <h3 class="anchor-heading"><a id="adminapi" class="anchor-link"></a><a href="#adminapi">2.6 Admin API</a></h3>
-
- The Admin API supports managing and inspecting topics, brokers, acls, and other Kafka objects.
- <p>
- To use the Admin API, add the following Maven dependency to your project:
- <pre class="line-numbers"><code class="language-xml"><dependency>
- <groupId>org.apache.kafka</groupId>
- <artifactId>kafka-clients</artifactId>
- <version>{{fullDotVersion}}</version>
-</dependency></code></pre>
- For more information about the Admin APIs, see the <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/admin/Admin.html" title="Kafka {{dotVersion}} Javadoc">javadoc</a>.
- <p>
-
-</script>
-
-<div class="p-api"></div>
diff --git a/docs/apis/_index.md b/docs/apis/_index.md
new file mode 100644
index 00000000000..062fce80757
--- /dev/null
+++ b/docs/apis/_index.md
@@ -0,0 +1,133 @@
+---
+title: API
+description:
+weight: 2
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Kafka includes six core apis:
+
+ 1. The Producer API allows applications to send streams of data to topics in the Kafka cluster.
+ 2. The Consumer API allows applications to read streams of data from topics in the Kafka cluster.
+ 3. The Share consumer API allows applications in a share group to cooperatively consume and process data from Kafka topics.
+ 4. The Streams API allows transforming streams of data from input topics to output topics.
+ 5. The Connect API allows implementing connectors that continually pull from some source system or application into Kafka or push from Kafka into some sink system or application.
+ 6. The Admin API allows managing and inspecting topics, brokers, and other Kafka objects.
+Kafka exposes all its functionality over a language-independent protocol which has clients available in many programming languages. However only the Java clients are maintained as part of the main Kafka project, the others are available as independent open source projects. A list of non-Java clients is available [here](https://cwiki.apache.org/confluence/x/3gDVAQ).
+
+# Producer API
+
+The Producer API allows applications to send streams of data to topics in the Kafka cluster.
+
+Examples of using the producer are shown in the [javadocs](/42/javadoc/index.html?org/apache/kafka/clients/producer/KafkaProducer.html "Kafka 4.2 Javadoc").
+
+To use the producer, add the following Maven dependency to your project:
+
+
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+
+# Consumer API
+
+The Consumer API allows applications to read streams of data from topics in the Kafka cluster.
+
+Examples of using the consumer are shown in the [javadocs](/42/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html "Kafka 4.2 Javadoc").
+
+To use the consumer, add the following Maven dependency to your project:
+
+
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+
+# Share Consumer API
+
+The Share Consumer API enables applications in a share group to cooperatively consume and process data from Kafka topics.
+
+Examples of using the share consumer are shown in the [javadocs](/42/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaShareConsumer.html "Kafka 4.2 Javadoc").
+
+To use the share consumer, add the following Maven dependency to your project:
+
+
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+
+# Streams API
+
+The [Streams](/42/documentation/streams) API allows transforming streams of data from input topics to output topics.
+
+Examples of using this library are shown in the [javadocs](/42/javadoc/index.html?org/apache/kafka/streams/KafkaStreams.html "Kafka 4.2 Javadoc").
+
+Additional documentation on using the Streams API is available [here](/42/documentation/streams).
+
+To use Kafka Streams, add the following Maven dependency to your project:
+
+
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-streams</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+
+When using Scala you may optionally include the `kafka-streams-scala` library. Additional documentation on using the Kafka Streams DSL for Scala is available [in the developer guide](/42/documentation/streams/developer-guide/dsl-api.html#scala-dsl).
+
+To use Kafka Streams DSL for Scala 2.13, add the following Maven dependency to your project:
+
+
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-streams-scala_2.13</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+
+# Connect API
+
+The Connect API allows implementing connectors that continually pull from some source data system into Kafka or push from Kafka into some sink data system.
+
+Many users of Connect won't need to use this API directly, though, they can use pre-built connectors without needing to write any code. Additional information on using Connect is available [here](/documentation.html#connect).
+
+Those who want to implement custom connectors can see the [javadoc](/42/javadoc/index.html?org/apache/kafka/connect "Kafka 4.2 Javadoc").
+
+# Admin API
+
+The Admin API supports managing and inspecting topics, brokers, acls, and other Kafka objects.
+
+To use the Admin API, add the following Maven dependency to your project:
+
+
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+
+For more information about the Admin APIs, see the [javadoc](/42/javadoc/index.html?org/apache/kafka/clients/admin/Admin.html "Kafka 4.2 Javadoc").
diff --git a/docs/compatibility-summary.html b/docs/compatibility-summary.html
deleted file mode 100644
index bb6f2d581bc..00000000000
--- a/docs/compatibility-summary.html
+++ /dev/null
@@ -1,27 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script><!--#include virtual="js/templateData.js" --></script>
-
-<script id="compatibility-summary-template" type="text/x-handlebars-template">
-<p>
- With the release of Kafka 4.0, significant changes have been introduced that impact compatibility across various
- components. To assist users in planning upgrades and ensuring seamless interoperability, a comprehensive
- <a href="/{{version}}/documentation/compatibility.html">compatibility matrix</a> has been prepared.
-</p>
-</script>
-<div class="p-compatibility-summary"></div>
diff --git a/docs/configuration.html b/docs/configuration.html
deleted file mode 100644
index 0c114f79ef4..00000000000
--- a/docs/configuration.html
+++ /dev/null
@@ -1,471 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script id="configuration-template" type="text/x-handlebars-template">
- Kafka uses key-value pairs in the <a href="https://en.wikipedia.org/wiki/.properties">property file format</a> for configuration. These values can be supplied either from a file or programmatically.
-
- <h3 class="anchor-heading"><a id="brokerconfigs" class="anchor-link"></a><a href="#brokerconfigs">3.1 Broker Configs</a></h3>
-
- The essential configurations are the following:
- <ul>
- <li><code>node.id</code>
- <li><code>log.dirs</code>
- <li><code>process.roles</code>
- <li><code>controller.quorum.bootstrap.servers</code>
- <li><code>controller.listener.names</code>
- </ul>
-
- Topic configurations and defaults are discussed in more detail <a href="#topicconfigs">below</a>.
-
- <!--#include virtual="generated/kafka_config.html" -->
-
- <p>More details about broker configuration can be found in the scala class <code>kafka.server.KafkaConfig</code>.</p>
-
- <h4 class="anchor-heading"><a id="dynamicbrokerconfigs" class="anchor-link"></a><a href="#dynamicbrokerconfigs">3.1.1 Updating Broker Configs</a></h4>
- From Kafka version 1.1 onwards, some of the broker configs can be updated without restarting the broker. See the
- <code>Dynamic Update Mode</code> column in <a href="#brokerconfigs">Broker Configs</a> for the update mode of each broker config.
- <ul>
- <li><code>read-only</code>: Requires a broker restart for update</li>
- <li><code>per-broker</code>: May be updated dynamically for each broker</li>
- <li><code>cluster-wide</code>: May be updated dynamically as a cluster-wide default. May also be updated as a per-broker value for testing.</li>
- </ul>
-
- To alter the current broker configs for broker id 0 (for example, the number of log cleaner threads):
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2</code></pre>
-
- To describe the current dynamic broker configs for broker id 0:
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe</code></pre>
-
- To delete a config override and revert to the statically configured or default value for broker id 0 (for example,
- the number of log cleaner threads):
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threads</code></pre>
-
- Some configs may be configured as a cluster-wide default to maintain consistent values across the whole cluster. All brokers
- in the cluster will process the cluster default update. For example, to update log cleaner threads on all brokers:
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=2</code></pre>
-
- To describe the currently configured dynamic cluster-wide default configs:
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe</code></pre>
-
- All configs that are configurable at cluster level may also be configured at per-broker level (e.g. for testing).
- If a config value is defined at different levels, the following order of precedence is used:
- <ul>
- <li>Dynamic per-broker config stored in the metadata log</li>
- <li>Dynamic cluster-wide default config stored in the metadata log</li>
- <li>Static broker config from <code>server.properties</code></li>
- <li>Kafka default, see <a href="#brokerconfigs">broker configs</a></li>
- </ul>
-
- <h5>Updating SSL Keystore of an Existing Listener</h5>
- Brokers may be configured with SSL keystores with short validity periods to reduce the risk of compromised certificates.
- Keystores may be updated dynamically without restarting the broker. The config name must be prefixed with the listener prefix
- <code>listener.name.{listenerName}.</code> so that only the keystore config of a specific listener is updated.
- The following configs may be updated in a single alter request at per-broker level:
- <ul>
- <li><code>ssl.keystore.type</code></li>
- <li><code>ssl.keystore.location</code></li>
- <li><code>ssl.keystore.password</code></li>
- <li><code>ssl.key.password</code></li>
- </ul>
- If the listener is the inter-broker listener, the update is allowed only if the new keystore is trusted by the truststore
- configured for that listener. For other listeners, no trust validation is performed on the keystore by the broker. Certificates
- must be signed by the same certificate authority that signed the old certificate to avoid any client authentication failures.
-
- <h5>Updating SSL Truststore of an Existing Listener</h5>
- Broker truststores may be updated dynamically without restarting the broker to add or remove certificates.
- Updated truststore will be used to authenticate new client connections. The config name must be prefixed with the
- listener prefix <code>listener.name.{listenerName}.</code> so that only the truststore config of a specific listener
- is updated. The following configs may be updated in a single alter request at per-broker level:
- <ul>
- <li><code>ssl.truststore.type</code></li>
- <li><code>ssl.truststore.location</code></li>
- <li><code>ssl.truststore.password</code></li>
- </ul>
- If the listener is the inter-broker listener, the update is allowed only if the existing keystore for that listener is trusted by
- the new truststore. For other listeners, no trust validation is performed by the broker before the update. Removal of CA certificates
- used to sign client certificates from the new truststore can lead to client authentication failures.
-
- <h5>Updating Default Topic Configuration</h5>
- Default topic configuration options used by brokers may be updated without broker restart. The configs are applied to topics
- without a topic config override for the equivalent per-topic config. One or more of these configs may be overridden at
- cluster-default level used by all brokers.
- <ul>
- <li><code>log.segment.bytes</code></li>
- <li><code>log.roll.ms</code></li>
- <li><code>log.roll.hours</code></li>
- <li><code>log.roll.jitter.ms</code></li>
- <li><code>log.roll.jitter.hours</code></li>
- <li><code>log.index.size.max.bytes</code></li>
- <li><code>log.flush.interval.messages</code></li>
- <li><code>log.flush.interval.ms</code></li>
- <li><code>log.retention.bytes</code></li>
- <li><code>log.retention.ms</code></li>
- <li><code>log.retention.minutes</code></li>
- <li><code>log.retention.hours</code></li>
- <li><code>log.index.interval.bytes</code></li>
- <li><code>log.cleaner.delete.retention.ms</code></li>
- <li><code>log.cleaner.min.compaction.lag.ms</code></li>
- <li><code>log.cleaner.max.compaction.lag.ms</code></li>
- <li><code>log.cleaner.min.cleanable.ratio</code></li>
- <li><code>log.cleanup.policy</code></li>
- <li><code>log.segment.delete.delay.ms</code></li>
- <li><code>unclean.leader.election.enable</code></li>
- <li><code>min.insync.replicas</code></li>
- <li><code>max.message.bytes</code></li>
- <li><code>compression.type</code></li>
- <li><code>log.preallocate</code></li>
- <li><code>log.message.timestamp.type</code></li>
- </ul>
-
- <h5>Updating Log Cleaner Configs</h5>
- Log cleaner configs may be updated dynamically at cluster-default level used by all brokers. The changes take effect
- on the next iteration of log cleaning. One or more of these configs may be updated:
- <ul>
- <li><code>log.cleaner.threads</code></li>
- <li><code>log.cleaner.io.max.bytes.per.second</code></li>
- <li><code>log.cleaner.dedupe.buffer.size</code></li>
- <li><code>log.cleaner.io.buffer.size</code></li>
- <li><code>log.cleaner.io.buffer.load.factor</code></li>
- <li><code>log.cleaner.backoff.ms</code></li>
- </ul>
-
- <h5>Updating Thread Configs</h5>
- The size of various thread pools used by the broker may be updated dynamically at cluster-default level used by all brokers.
- Updates are restricted to the range <code>currentSize / 2</code> to <code>currentSize * 2</code> to ensure that config updates are
- handled gracefully.
- <ul>
- <li><code>num.network.threads</code></li>
- <li><code>num.io.threads</code></li>
- <li><code>num.replica.fetchers</code></li>
- <li><code>num.recovery.threads.per.data.dir</code></li>
- <li><code>log.cleaner.threads</code></li>
- <li><code>background.threads</code></li>
- <li><code>remote.log.reader.threads</code></li>
- <li><code>remote.log.manager.copier.thread.pool.size</code></li>
- <li><code>remote.log.manager.expiration.thread.pool.size</code></li>
- <li><code>remote.log.manager.follower.thread.pool.size</code></li>
- </ul>
-
- <h5>Updating ConnectionQuota Configs</h5>
- The maximum number of connections allowed for a given IP/host by the broker may be updated dynamically at cluster-default level used by all brokers.
- The changes will apply for new connection creations and the existing connections count will be taken into account by the new limits.
- <ul>
- <li><code>max.connections.per.ip</code></li>
- <li><code>max.connections.per.ip.overrides</code></li>
- </ul>
-
- <h5>Adding and Removing Listeners</h5>
- <p>Listeners may be added or removed dynamically. When a new listener is added, security configs of the listener must be provided
- as listener configs with the listener prefix <code>listener.name.{listenerName}.</code>. If the new listener uses SASL,
- the JAAS configuration of the listener must be provided using the JAAS configuration property <code>sasl.jaas.config</code>
- with the listener and mechanism prefix. See <a href="#security_jaas_broker">JAAS configuration for Kafka brokers</a> for details.</p>
-
- <p>In Kafka version 1.1.x, the listener used by the inter-broker listener may not be updated dynamically. To update the inter-broker
- listener to a new listener, the new listener may be added on all brokers without restarting the broker. A rolling restart is then
- required to update <code>inter.broker.listener.name</code>.</p>
-
- In addition to all the security configs of new listeners, the following configs may be updated dynamically at per-broker level:
- <ul>
- <li><code>listeners</code></li>
- <li><code>advertised.listeners</code></li>
- <li><code>listener.security.protocol.map</code></li>
- </ul>
- Inter-broker listener must be configured using the static broker configuration <code>inter.broker.listener.name</code>
- or <code>security.inter.broker.protocol</code>.
-
- <h3 class="anchor-heading"><a id="topicconfigs" class="anchor-link"></a><a href="#topicconfigs">3.2 Topic Configs</a></h3>
-
- Configurations pertinent to topics have both a server default as well an optional per-topic override. If no per-topic configuration is given the server default is used. The override can be set at topic creation time by giving one or more <code>--config</code> options. This example creates a topic named <i>my-topic</i> with a custom max message size and flush rate:
- <pre><code class="language-bash">$ bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-topic --partitions 1 \
- --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1</code></pre>
- Overrides can also be changed or set later using the alter configs command. This example updates the max message size for <i>my-topic</i>:
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
- --alter --add-config max.message.bytes=128000</code></pre>
-
- To check overrides set on the topic you can do
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe</code></pre>
-
- To remove an override you can do
- <pre><code class="language-bash">$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
- --alter --delete-config max.message.bytes</code></pre>
-
- Below is the topic configuration. The server's default configuration for this property is given under the Server Default Property heading. A given server default config value only applies to a topic if it does not have an explicit topic config override.
-
- <!--#include virtual="generated/topic_config.html" -->
-
- <h3 class="anchor-heading"><a id="groupconfigs" class="anchor-link"></a><a href="#groupconfigs">3.3 Group Configs</a></h3>
-
- Below is the group configuration:
- <!--#include virtual="generated/group_config.html" -->
-
- <h3 class="anchor-heading"><a id="producerconfigs" class="anchor-link"></a><a href="#producerconfigs">3.4 Producer Configs</a></h3>
-
- Below is the producer configuration:
- <!--#include virtual="generated/producer_config.html" -->
-
- <h3 class="anchor-heading"><a id="consumerconfigs" class="anchor-link"></a><a href="#consumerconfigs">3.5 Consumer Configs</a></h3>
-
- Below is the consumer and share consumer configuration:
- <!--#include virtual="generated/consumer_config.html" -->
-
- <h3 class="anchor-heading"><a id="connectconfigs" class="anchor-link"></a><a href="#connectconfigs">3.6 Kafka Connect Configs</a></h3>
- Below is the Kafka Connect framework configuration.
- <!--#include virtual="generated/connect_config.html" -->
-
- <h4 class="anchor-heading"><a id="sourceconnectconfigs" class="anchor-link"></a><a href="#sourceconnectconfigs">3.6.1 Source Connector Configs</a></h4>
- Below is the source connector configuration.
- <!--#include virtual="generated/source_connector_config.html" -->
-
- <h4 class="anchor-heading"><a id="sinkconnectconfigs" class="anchor-link"></a><a href="#sinkconnectconfigs">3.6.2 Sink Connector Configs</a></h4>
- Below is the sink connector configuration.
- <!--#include virtual="generated/sink_connector_config.html" -->
-
- <h3 class="anchor-heading"><a id="streamsconfigs" class="anchor-link"></a><a href="#streamsconfigs">3.7 Kafka Streams Configs</a></h3>
- Below is the Kafka Streams client library configuration.
- <!--#include virtual="generated/streams_config.html" -->
-
- <h3 class="anchor-heading"><a id="adminclientconfigs" class="anchor-link"></a><a href="#adminclientconfigs">3.8 Admin Configs</a></h3>
- Below is the Kafka Admin client library configuration.
- <!--#include virtual="generated/admin_client_config.html" -->
-
- <h3 class="anchor-heading"><a id="mirrormakerconfigs" class="anchor-link"></a><a href="#mirrormakerconfigs">3.9 MirrorMaker Configs</a></h3>
- Below is the configuration of the connectors that make up MirrorMaker 2.
-
- <h4 class="anchor-heading"><a id="mirrormakercommonconfigs" class="anchor-link"></a><a href="#mirrormakercommonconfigs">3.9.1 MirrorMaker Common Configs</a></h4>
- Below is the common configuration that applies to all three connectors.
- <!--#include virtual="generated/mirror_connector_config.html" -->
-
- <h4 class="anchor-heading"><a id="mirrormakersourceconfigs" class="anchor-link"></a><a href="#mirrormakersourceconfigs">3.9.2 MirrorMaker Source Configs</a></h4>
- Below is the configuration of MirrorMaker 2 source connector for replicating topics.
- <!--#include virtual="generated/mirror_source_config.html" -->
-
- <h4 class="anchor-heading"><a id="mirrormakercheckpointconfigs" class="anchor-link"></a><a href="#mirrormakercheckpointconfigs">3.9.3 MirrorMaker Checkpoint Configs</a></h4>
- Below is the configuration of MirrorMaker 2 checkpoint connector for emitting consumer offset checkpoints.
- <!--#include virtual="generated/mirror_checkpoint_config.html" -->
-
- <h4 class="anchor-heading"><a id="mirrormakerheartbeatconfigs" class="anchor-link"></a><a href="#mirrormakerheartbeatconfigs">3.9.4 MirrorMaker HeartBeat Configs</a></h4>
- Below is the configuration of MirrorMaker 2 heartbeat connector for checking connectivity between connectors and clusters.
- <!--#include virtual="generated/mirror_heartbeat_config.html" -->
-
- <h3 class="anchor-heading"><a id="systemproperties" class="anchor-link"></a><a href="#systemproperties">3.10 System Properties</a></h3>
- Kafka supports some configuration that can be enabled through Java system properties. System properties are usually set by passing the -D flag to the Java virtual machine in which Kafka components are running.
- Below are the supported system properties.
- <ul class="config-list">
- <li>
- <h4><a id="org.apache.kafka.sasl.oauthbearer.allowed.files"></a><a id="systemproperties_org.apache.kafka.sasl.oauthbearer.allowed.files" href="#systemproperties_org.apache.kafka.sasl.oauthbearer.allowed.files">org.apache.kafka.sasl.oauthbearer.allowed.files</a></h4>
- <p>This system property is used to determine which files, if any, are allowed to be read by the SASL OAUTHBEARER plugin. This property accepts comma-separated list of files. By default the value is an empty list.
- <p>If users want to enable some files, users need to explicitly set the system property like below.
- <p><pre><code class="language-bash">-Dorg.apache.kafka.sasl.oauthbearer.allowed.files=/tmp/token,/tmp/private_key.pem</code></pre>
- <table><tbody>
- <tr><th>Since:</th><td>4.1.0</td></tr>
- <tr><th>Default Value:</th><td></td></tr>
- </tbody></table>
- </li>
- <li>
- <h4><a id="org.apache.kafka.sasl.oauthbearer.allowed.urls"></a><a id="systemproperties_org.apache.kafka.sasl.oauthbearer.allowed.urls" href="#systemproperties_org.apache.kafka.sasl.oauthbearer.allowed.urls">org.apache.kafka.sasl.oauthbearer.allowed.urls</a></h4>
- <p>This system property is used to set the allowed URLs as SASL OAUTHBEARER token or jwks endpoints. This property accepts comma-separated list of URLs. By default the value is an empty list.
- <p>If users want to enable some URLs, users need to explicitly set the system property like below.
- <p><pre><code class="language-bash">-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls=https://www.example.com,file:///tmp/token</code></pre>
- <table><tbody>
- <tr><th>Since:</th><td>4.0.0</td></tr>
- <tr><th>Default Value:</th><td></td></tr>
- </tbody></table>
- </li>
- <li>
- <h4><a id="org.apache.kafka.disallowed.login.modules"></a><a id="systemproperties_org.apache.kafka.disallowed.login.modules" href="#systemproperties_org.apache.kafka.disallowed.login.modules">org.apache.kafka.disallowed.login.modules</a></h4>
- <p>This system property is used to disable the problematic login modules usage in SASL JAAS configuration. This property accepts comma-separated list of loginModule names. By default <b>com.sun.security.auth.module.JndiLoginModule</b> and <b>com.sun.security.auth.module.LdapLoginModule</b> loginModule is disabled.
- <p>If users want to enable JndiLoginModule or LdapLoginModule, users need to explicitly reset the system property like below. We advise the users to validate configurations and only allow trusted JNDI configurations. For more details <a href="https://kafka.apache.org/cve-list#CVE-2023-25194">CVE-2023-25194</a>.
- <p><pre><code class="language-bash">-Dorg.apache.kafka.disallowed.login.modules=</code></pre>
- <p>To disable more loginModules, update the system property with comma-separated loginModule names. Make sure to explicitly add <b>JndiLoginModule</b> module name to the comma-separated list like below.
- <p><pre><code class="language-bash">-Dorg.apache.kafka.disallowed.login.modules=com.sun.security.auth.module.JndiLoginModule,com.ibm.security.auth.module.LdapLoginModule,com.ibm.security.auth.module.Krb5LoginModule</code></pre>
- <p>The configuration is deprecated and will be removed in a future release. Please use <b>org.apache.kafka.allowed.login.modules</b> instead.
- <table><tbody>
- <tr><th>Since:</th><td>3.4.0</td></tr>
- <tr><th>Deprecated:</th><td>4.2.0</td></tr>
- <tr><th>Default Value:</th><td>com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule</td></tr>
- </tbody></table>
- </li>
- <li>
- <h4><a id="org.apache.kafka.allowed.login.modules"></a><a id="systemproperties_org.apache.kafka.allowed.login.modules" href="#systemproperties_org.apache.kafka.allowed.login.modules">org.apache.kafka.allowed.login.modules</a></h4>
- <p>This system property is used to explicitly allow specific login modules in SASL JAAS configuration. It accepts a comma-separated list of login module class names. This property provides a stricter, allowed-list-based alternative to the deprecated <code>org.apache.kafka.disallowed.login.modules</code> property.
- It is recommended to use this property to improve the security of JAAS configurations.
- <p>If both properties are set, <code>org.apache.kafka.allowed.login.modules</code> takes precedence.</p>
- <table><tbody>
- <tr><th>Since:</th><td>4.2.0</td></tr>
- <tr><th>Default Value:</th></tr>
- </tbody></table>
- </li>
- <li>
- <h4><a id="org.apache.kafka.automatic.config.providers"></a><a id="systemproperties_org.apache.kafka.automatic.config.providers" href="#systemproperties_org.apache.kafka.automatic.config.providers">org.apache.kafka.automatic.config.providers</a></h4>
- <p>This system property controls the automatic loading of ConfigProvider implementations in Apache Kafka. ConfigProviders are used to dynamically supply configuration values from sources such as files, directories, or environment variables. This property accepts a comma-separated list of ConfigProvider names. By default, all built-in ConfigProviders are enabled, including <b>FileConfigProvider</b>, <b>DirectoryConfigProvider</b>, and <b>EnvVarConfigProvider</b>.</p>
- <p>If users want to disable all automatic ConfigProviders, they need to explicitly set the system property as shown below. Disabling automatic ConfigProviders is recommended in environments where configuration data comes from untrusted sources or where increased security is required. For more details, see <a href="https://kafka.apache.org/cve-list#CVE-2024-31141">CVE-2024-31141</a>.</p>
- <pre><code class="language-bash">-Dorg.apache.kafka.automatic.config.providers=none</code></pre>
- <p>To allow specific ConfigProviders, update the system property with a comma-separated list of fully qualified ConfigProvider class names. For example, to enable only the <b>EnvVarConfigProvider</b>, set the property as follows:</p>
- <pre><code class="language-bash">-Dorg.apache.kafka.automatic.config.providers=org.apache.kafka.common.config.provider.EnvVarConfigProvider</code></pre>
- <p>To use multiple ConfigProviders, include their names in a comma-separated list as shown below:</p>
- <pre><code class="language-bash">-Dorg.apache.kafka.automatic.config.providers=org.apache.kafka.common.config.provider.FileConfigProvider,org.apache.kafka.common.config.provider.EnvVarConfigProvider</code></pre>
- <table>
- <tbody>
- <tr><th>Since:</th><td>3.8.0</td></tr>
- <tr><th>Default Value:</th><td>All built-in ConfigProviders are enabled</td></tr>
- </tbody>
- </table>
- </li>
- </ul>
-
- <h3 class="anchor-heading"><a id="tieredstorageconfigs" class="anchor-link"></a><a href="#tieredstorageconfigs">3.11 Tiered Storage Configs</a></h3>
- Below is the Tiered Storage configuration.
- <!--#include virtual="generated/remote_log_manager_config.html" -->
-
- <h4 class="anchor-heading"><a id="rlmmconfigs" class="anchor-link"></a><a href="#rlmmconfigs">3.11.1 RLMM Configs</a></h4>
- <p>Below is the configuration for <code>TopicBasedRemoteLogMetadataManager</code>, which is the default implementation of <code>RemoteLogMetadataManager</code>.</p>
- <p>All configurations here should start with the prefix defined by <code>remote.log.metadata.manager.impl.prefix</code>, for example, <code>rlmm.config.remote.log.metadata.consume.wait.ms</code>.</p>
- <!--#include virtual="generated/remote_log_metadata_manager_config.html" -->
-
- <p>The implementation of <code>TopicBasedRemoteLogMetadataManager</code> needs to create admin, producer, and consumer clients for the internal topic <code>__remote_log_metadata</code>.</p>
- <p>Additional configurations can be provided for different types of clients using the following configuration properties: </p>
- <pre><code class="language-text"># Configs for admin, producer, and consumer clients
-<rlmm.prefix>.remote.log.metadata.common.client.<kafka.property> = <value>
-
-# Configs only for producer client
-<rlmm.prefix>.remote.log.metadata.producer.<kafka.property> = <value>
-
-# Configs only for consumer client
-<rlmm.prefix>.remote.log.metadata.consumer.<kafka.property> = <value></code></pre>
-
- <h3 class="anchor-heading">
- <a id="config_providers" class="anchor-link"></a>
- <a href="#config_providers">3.12 Configuration Providers</a>
- </h3>
-
- <p>
- Use configuration providers to load configuration data from external sources. This might include sensitive information, such as passwords, API keys, or other credentials.
- </p>
-
- <p>You have the following options:</p>
- <ul>
- <li>
- Use a custom provider by creating a class implementing the
- <a href="/{{version}}/javadoc/org/apache/kafka/common/config/provider/ConfigProvider.html"><code>ConfigProvider</code></a> interface and packaging it into a JAR file.
- </li>
- <li>Use a built-in provider:</li>
- <ul>
- <li><a href="/{{version}}/javadoc/org/apache/kafka/common/config/provider/DirectoryConfigProvider.html"><code>DirectoryConfigProvider</code></a></li>
- <li><a href="/{{version}}/javadoc/org/apache/kafka/common/config/provider/EnvVarConfigProvider.html"><code>EnvVarConfigProvider</code></a></li>
- <li><a href="/{{version}}/javadoc/org/apache/kafka/common/config/provider/FileConfigProvider.html"><code>FileConfigProvider</code></a></li>
- </ul>
- </ul>
-
- <p>
- To use a configuration provider, specify it in your configuration using the <code>config.providers</code> property.
- </p>
-
- <h4 class="anchor-heading">
- <a id="using_config_providers" class="anchor-link"></a>
- <a href="#using_config_providers">Using Configuration Providers</a>
- </h4>
- <p>Configuration providers allow you to pass parameters and retrieve configuration data from various sources.</p>
- <p>To specify configuration providers, you use a comma-separated list of aliases and the fully-qualified class names that implement the configuration providers:</p>
- <pre><code>config.providers=provider1,provider2
-config.providers.provider1.class=com.example.Provider1
-config.providers.provider2.class=com.example.Provider2</code></pre>
- <p>Each provider can have its own set of parameters, which are passed in a specific format:</p>
- <pre><code>config.providers.<provider_alias>.param.<name>=<value></code></pre>
- <p>The <code>ConfigProvider</code> interface serves as a base for all configuration providers.
- Custom implementations of this interface can be created to retrieve configuration data from various sources.
- You can package the implementation as a JAR file, add the JAR to your classpath, and reference the provider's class in your configuration.</p>
- <p><b>Example custom provider configuration</b></p>
- <pre><code>config.providers=customProvider
-config.providers.customProvider.class=com.example.customProvider
-config.providers.customProvider.param.param1=value1
-config.providers.customProvider.param.param2=value2</code></pre>
-
- <h4 class="anchor-heading">
- <a id="directory_config_provider" class="anchor-link"></a>
- <a href="#directory_config_provider">DirectoryConfigProvider</a>
- </h4>
- <p>The <code>DirectoryConfigProvider</code> retrieves configuration data from files stored in a specified directory.</p>
- <p>Each file represents a key, and its content is the value. This provider is useful for loading multiple configuration files and for organizing configuration data into separate files.</p>
- <p>To restrict the files that the <code>DirectoryConfigProvider</code> can access, use the <code>allowed.paths</code> parameter.
- This parameter accepts a comma-separated list of paths that the provider is allowed to access. If not set, all paths are allowed.</p>
- <p><b>Example <code>DirectoryConfigProvider</code> configuration</b></p>
-<pre><code>config.providers=dirProvider
-config.providers.dirProvider.class=org.apache.kafka.common.config.provider.DirectoryConfigProvider
-config.providers.dirProvider.param.allowed.paths=/path/to/dir1,/path/to/dir2</code></pre>
- <p>
- To reference a value supplied by the <code>DirectoryConfigProvider</code>, use the correct placeholder syntax:
- </p>
-<pre><code>${dirProvider:<path_to_file>:<file_name>}</code></pre>
-
- <h4 class="anchor-heading">
- <a id="env_var_config_provider" class="anchor-link"></a>
- <a href="#env_var_config_provider">EnvVarConfigProvider</a>
- </h4>
- <p>The <code>EnvVarConfigProvider</code> retrieves configuration data from environment variables.</p>
- <p>No specific parameters are required, as it reads directly from the specified environment variables.</p>
- <p>This provider is useful for configuring applications running in containers, for example, to load certificates or JAAS configuration from environment variables mapped from secrets.</p>
- <p>To restrict which environment variables the <code>EnvVarConfigProvider</code> can access, use the <code>allowlist.pattern</code> parameter. This parameter accepts a regular expression that environment variable names must match to be used by the provider.</p>
- <p><b>Example <code>EnvVarConfigProvider</code> configuration</b></p>
-<pre><code>config.providers=envVarProvider
-config.providers.envVarProvider.class=org.apache.kafka.common.config.provider.EnvVarConfigProvider
-config.providers.envVarProvider.param.allowlist.pattern=^MY_ENVAR1_.*</code></pre>
- <p>
- To reference a value supplied by the <code>EnvVarConfigProvider</code>, use the correct placeholder syntax:
- </p>
-<pre><code>${envVarProvider:<enVar_name>}</code></pre>
-
- <h4 class="anchor-heading">
- <a id="file_config_provider" class="anchor-link"></a>
- <a href="#file_config_provider">FileConfigProvider</a>
- </h4>
- <p>The <code>FileConfigProvider</code> retrieves configuration data from a single properties file.</p>
- <p>This provider is useful for loading configuration data from mounted files.</p>
- <p>To restrict the file paths that the <code>FileConfigProvider</code> can access, use the <code>allowed.paths</code> parameter. This parameter accepts a comma-separated list of paths that the provider is allowed to access. If not set, all paths are allowed.</p>
- <p><b>Example <code>FileConfigProvider</code> configuration</b></p>
-<pre><code>config.providers=fileProvider
-config.providers.fileProvider.class=org.apache.kafka.common.config.provider.FileConfigProvider
-config.providers.fileProvider.param.allowed.paths=/path/to/config1,/path/to/config2</code></pre>
- <p>
- To reference a value supplied by the <code>FileConfigProvider</code>, use the correct placeholder syntax:
- </p>
-<pre><code>${fileProvider:<path_and_filename>:<property>}</code></pre>
-
- <h4 class="anchor-heading">
- <a id="ref_config_provider" class="anchor-link"></a>
- <a href="#ref_config_provider">Example: Referencing files</a>
- </h4>
- <p>
- Here’s an example that uses a file configuration provider with Kafka Connect to provide authentication credentials to a database for a connector.
- </p>
- <p>
- First, create a <code>connector-credentials.properties</code> configuration file with the following credentials:
- </p>
- <pre><code>dbUsername=my-username
-dbPassword=my-password</code></pre>
- <p>
- Specify a <code>FileConfigProvider</code> in the Kafka Connect configuration:
- </p>
- <p><b>Example Kafka Connect configuration with a <code>FileConfigProvider</code></b></p>
- <pre><code>config.providers=fileProvider
-config.providers.fileProvider.class=org.apache.kafka.common.config.provider.FileConfigProvider</code></pre>
- <p>Next, reference the properties from the file in the connector configuration.</p>
- <p><b>Example connector configuration referencing file properties</b></p>
- <pre><code>database.user=${fileProvider:/path/to/connector-credentials.properties:dbUsername}
-database.password=${fileProvider:/path/to/connector-credentials.properties:dbPassword}</code></pre>
- <p>At runtime, the configuration provider reads and extracts the values from the properties file.</p>
-</script>
-<div class="p-configuration"></div>
diff --git a/docs/documentation/streams/core-concepts.html b/docs/configuration/_index.md
similarity index 85%
rename from docs/documentation/streams/core-concepts.html
rename to docs/configuration/_index.md
index d699b795000..31842e12b13 100644
--- a/docs/documentation/streams/core-concepts.html
+++ b/docs/configuration/_index.md
@@ -1,3 +1,13 @@
+---
+title: Configuration
+description:
+weight: 3
+tags: ['kafka', 'docs', 'configuration']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,5 +25,4 @@
limitations under the License.
-->
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../streams/core-concepts.html" -->
+
diff --git a/docs/documentation/index.html b/docs/configuration/admin-configs.md
similarity index 75%
copy from docs/documentation/index.html
copy to docs/configuration/admin-configs.md
index 1d7507f30a9..6a377252b1a 100644
--- a/docs/documentation/index.html
+++ b/docs/configuration/admin-configs.md
@@ -1,3 +1,13 @@
+---
+title: Admin Configs
+description: Admin Configs
+weight: 8
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+Below is the Kafka Admin client library configuration. {{< include-html file="/static/42/generated/admin_client_config.html" >}}
diff --git a/docs/configuration/broker-configs.md b/docs/configuration/broker-configs.md
new file mode 100644
index 00000000000..96f77ba0d1b
--- /dev/null
+++ b/docs/configuration/broker-configs.md
@@ -0,0 +1,186 @@
+---
+title: Broker Configs
+description: Broker Configs
+weight: 1
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+The essential configurations are the following:
+
+ * `node.id`
+ * `log.dirs`
+ * `process.roles`
+ * `controller.quorum.bootstrap.servers`
+ * `controller.listener.names`
+Topic configurations and defaults are discussed in more detail below. {{< include-html file="/static/42/generated/kafka_config.html" >}}
+
+More details about broker configuration can be found in the scala class `kafka.server.KafkaConfig`.
+
+## Updating Broker Configs
+
+From Kafka version 1.1 onwards, some of the broker configs can be updated without restarting the broker. See the `Dynamic Update Mode` column in Broker Configs for the update mode of each broker config.
+
+ * `read-only`: Requires a broker restart for update
+ * `per-broker`: May be updated dynamically for each broker
+ * `cluster-wide`: May be updated dynamically as a cluster-wide default. May also be updated as a per-broker value for testing.
+
+To alter the current broker configs for broker id 0 (for example, the number of log cleaner threads):
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2
+
+To describe the current dynamic broker configs for broker id 0:
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe
+
+To delete a config override and revert to the statically configured or default value for broker id 0 (for example, the number of log cleaner threads):
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threads
+
+Some configs may be configured as a cluster-wide default to maintain consistent values across the whole cluster. All brokers in the cluster will process the cluster default update. For example, to update log cleaner threads on all brokers:
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=2
+
+To describe the currently configured dynamic cluster-wide default configs:
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe
+
+All configs that are configurable at cluster level may also be configured at per-broker level (e.g. for testing). If a config value is defined at different levels, the following order of precedence is used:
+
+ * Dynamic per-broker config stored in the metadata log
+ * Dynamic cluster-wide default config stored in the metadata log
+ * Static broker config from `server.properties`
+ * Kafka default, see broker configs
+
+
+
+### Updating SSL Keystore of an Existing Listener
+
+Brokers may be configured with SSL keystores with short validity periods to reduce the risk of compromised certificates. Keystores may be updated dynamically without restarting the broker. The config name must be prefixed with the listener prefix `listener.name.{listenerName}.` so that only the keystore config of a specific listener is updated. The following configs may be updated in a single alter request at per-broker level:
+
+ * `ssl.keystore.type`
+ * `ssl.keystore.location`
+ * `ssl.keystore.password`
+ * `ssl.key.password`
+
+If the listener is the inter-broker listener, the update is allowed only if the new keystore is trusted by the truststore configured for that listener. For other listeners, no trust validation is performed on the keystore by the broker. Certificates must be signed by the same certificate authority that signed the old certificate to avoid any client authentication failures.
+
+### Updating SSL Truststore of an Existing Listener
+
+Broker truststores may be updated dynamically without restarting the broker to add or remove certificates. Updated truststore will be used to authenticate new client connections. The config name must be prefixed with the listener prefix `listener.name.{listenerName}.` so that only the truststore config of a specific listener is updated. The following configs may be updated in a single alter request at per-broker level:
+
+ * `ssl.truststore.type`
+ * `ssl.truststore.location`
+ * `ssl.truststore.password`
+
+If the listener is the inter-broker listener, the update is allowed only if the existing keystore for that listener is trusted by the new truststore. For other listeners, no trust validation is performed by the broker before the update. Removal of CA certificates used to sign client certificates from the new truststore can lead to client authentication failures.
+
+### Updating Default Topic Configuration
+
+Default topic configuration options used by brokers may be updated without broker restart. The configs are applied to topics without a topic config override for the equivalent per-topic config. One or more of these configs may be overridden at cluster-default level used by all brokers.
+
+ * `log.segment.bytes`
+ * `log.roll.ms`
+ * `log.roll.hours`
+ * `log.roll.jitter.ms`
+ * `log.roll.jitter.hours`
+ * `log.index.size.max.bytes`
+ * `log.flush.interval.messages`
+ * `log.flush.interval.ms`
+ * `log.retention.bytes`
+ * `log.retention.ms`
+ * `log.retention.minutes`
+ * `log.retention.hours`
+ * `log.index.interval.bytes`
+ * `log.cleaner.delete.retention.ms`
+ * `log.cleaner.min.compaction.lag.ms`
+ * `log.cleaner.max.compaction.lag.ms`
+ * `log.cleaner.min.cleanable.ratio`
+ * `log.cleanup.policy`
+ * `log.segment.delete.delay.ms`
+ * `unclean.leader.election.enable`
+ * `min.insync.replicas`
+ * `max.message.bytes`
+ * `compression.type`
+ * `log.preallocate`
+ * `log.message.timestamp.type`
+
+
+
+### Updating Log Cleaner Configs
+
+Log cleaner configs may be updated dynamically at cluster-default level used by all brokers. The changes take effect on the next iteration of log cleaning. One or more of these configs may be updated:
+
+ * `log.cleaner.threads`
+ * `log.cleaner.io.max.bytes.per.second`
+ * `log.cleaner.dedupe.buffer.size`
+ * `log.cleaner.io.buffer.size`
+ * `log.cleaner.io.buffer.load.factor`
+ * `log.cleaner.backoff.ms`
+
+
+
+### Updating Thread Configs
+
+The size of various thread pools used by the broker may be updated dynamically at cluster-default level used by all brokers. Updates are restricted to the range `currentSize / 2` to `currentSize * 2` to ensure that config updates are handled gracefully.
+
+ * `num.network.threads`
+ * `num.io.threads`
+ * `num.replica.fetchers`
+ * `num.recovery.threads.per.data.dir`
+ * `log.cleaner.threads`
+ * `background.threads`
+ * `remote.log.reader.threads`
+ * `remote.log.manager.copier.thread.pool.size`
+ * `remote.log.manager.expiration.thread.pool.size`
+ * `remote.log.manager.follower.thread.pool.size`
+
+
+
+### Updating ConnectionQuota Configs
+
+The maximum number of connections allowed for a given IP/host by the broker may be updated dynamically at cluster-default level used by all brokers. The changes will apply for new connection creations and the existing connections count will be taken into account by the new limits.
+
+ * `max.connections.per.ip`
+ * `max.connections.per.ip.overrides`
+
+
+
+### Adding and Removing Listeners
+
+Listeners may be added or removed dynamically. When a new listener is added, security configs of the listener must be provided as listener configs with the listener prefix `listener.name.{listenerName}.`. If the new listener uses SASL, the JAAS configuration of the listener must be provided using the JAAS configuration property `sasl.jaas.config` with the listener and mechanism prefix. See JAAS configuration for Kafka brokers for details.
+
+In Kafka version 1.1.x, the listener used by the inter-broker listener may not be updated dynamically. To update the inter-broker listener to a new listener, the new listener may be added on all brokers without restarting the broker. A rolling restart is then required to update `inter.broker.listener.name`.
+
+In addition to all the security configs of new listeners, the following configs may be updated dynamically at per-broker level:
+
+ * `listeners`
+ * `advertised.listeners`
+ * `listener.security.protocol.map`
+
+Inter-broker listener must be configured using the static broker configuration `inter.broker.listener.name` or `security.inter.broker.protocol`.
diff --git a/docs/configuration/configuration-providers.md b/docs/configuration/configuration-providers.md
new file mode 100644
index 00000000000..971f3945c6e
--- /dev/null
+++ b/docs/configuration/configuration-providers.md
@@ -0,0 +1,157 @@
+---
+title: Configuration Providers
+description: Configuration Providers
+weight: 12
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Use configuration providers to load configuration data from external sources. This might include sensitive information, such as passwords, API keys, or other credentials.
+
+You have the following options:
+
+ * Use a custom provider by creating a class implementing the [`ConfigProvider`](/42/javadoc/org/apache/kafka/common/config/provider/ConfigProvider.html) interface and packaging it into a JAR file.
+ * Use a built-in provider:
+ * [`DirectoryConfigProvider`](/42/javadoc/org/apache/kafka/common/config/provider/DirectoryConfigProvider.html)
+ * [`EnvVarConfigProvider`](/42/javadoc/org/apache/kafka/common/config/provider/EnvVarConfigProvider.html)
+ * [`FileConfigProvider`](/42/javadoc/org/apache/kafka/common/config/provider/FileConfigProvider.html)
+
+
+
+To use a configuration provider, specify it in your configuration using the `config.providers` property.
+
+## Using Configuration Providers
+
+Configuration providers allow you to pass parameters and retrieve configuration data from various sources.
+
+To specify configuration providers, you use a comma-separated list of aliases and the fully-qualified class names that implement the configuration providers:
+
+
+ config.providers=provider1,provider2
+ config.providers.provider1.class=com.example.Provider1
+ config.providers.provider2.class=com.example.Provider2
+
+Each provider can have its own set of parameters, which are passed in a specific format:
+
+
+ config.providers.<provider_alias>.param.<name>=<value>
+
+The `ConfigProvider` interface serves as a base for all configuration providers. Custom implementations of this interface can be created to retrieve configuration data from various sources. You can package the implementation as a JAR file, add the JAR to your classpath, and reference the provider's class in your configuration.
+
+**Example custom provider configuration**
+
+
+ config.providers=customProvider
+ config.providers.customProvider.class=com.example.customProvider
+ config.providers.customProvider.param.param1=value1
+ config.providers.customProvider.param.param2=value2
+
+## DirectoryConfigProvider
+
+The `DirectoryConfigProvider` retrieves configuration data from files stored in a specified directory.
+
+Each file represents a key, and its content is the value. This provider is useful for loading multiple configuration files and for organizing configuration data into separate files.
+
+To restrict the files that the `DirectoryConfigProvider` can access, use the `allowed.paths` parameter. This parameter accepts a comma-separated list of paths that the provider is allowed to access. If not set, all paths are allowed.
+
+**Example`DirectoryConfigProvider` configuration**
+
+
+ config.providers=dirProvider
+ config.providers.dirProvider.class=org.apache.kafka.common.config.provider.DirectoryConfigProvider
+ config.providers.dirProvider.param.allowed.paths=/path/to/dir1,/path/to/dir2
+
+To reference a value supplied by the `DirectoryConfigProvider`, use the correct placeholder syntax:
+
+
+ ${dirProvider:<path_to_file>:<file_name>}
+
+## EnvVarConfigProvider
+
+The `EnvVarConfigProvider` retrieves configuration data from environment variables.
+
+No specific parameters are required, as it reads directly from the specified environment variables.
+
+This provider is useful for configuring applications running in containers, for example, to load certificates or JAAS configuration from environment variables mapped from secrets.
+
+To restrict which environment variables the `EnvVarConfigProvider` can access, use the `allowlist.pattern` parameter. This parameter accepts a regular expression that environment variable names must match to be used by the provider.
+
+**Example`EnvVarConfigProvider` configuration**
+
+
+ config.providers=envVarProvider
+ config.providers.envVarProvider.class=org.apache.kafka.common.config.provider.EnvVarConfigProvider
+ config.providers.envVarProvider.param.allowlist.pattern=^MY_ENVAR1_.*
+
+To reference a value supplied by the `EnvVarConfigProvider`, use the correct placeholder syntax:
+
+
+ ${envVarProvider:<enVar_name>}
+
+## FileConfigProvider
+
+The `FileConfigProvider` retrieves configuration data from a single properties file.
+
+This provider is useful for loading configuration data from mounted files.
+
+To restrict the file paths that the `FileConfigProvider` can access, use the `allowed.paths` parameter. This parameter accepts a comma-separated list of paths that the provider is allowed to access. If not set, all paths are allowed.
+
+**Example`FileConfigProvider` configuration**
+
+
+ config.providers=fileProvider
+ config.providers.fileProvider.class=org.apache.kafka.common.config.provider.FileConfigProvider
+ config.providers.fileProvider.param.allowed.paths=/path/to/config1,/path/to/config2
+
+To reference a value supplied by the `FileConfigProvider`, use the correct placeholder syntax:
+
+
+ ${fileProvider:<path_and_filename>:<property>}
+
+## Example: Referencing files
+
+Here’s an example that uses a file configuration provider with Kafka Connect to provide authentication credentials to a database for a connector.
+
+First, create a `connector-credentials.properties` configuration file with the following credentials:
+
+
+ dbUsername=my-username
+ dbPassword=my-password
+
+Specify a `FileConfigProvider` in the Kafka Connect configuration:
+
+**Example Kafka Connect configuration with a`FileConfigProvider`**
+
+
+ config.providers=fileProvider
+ config.providers.fileProvider.class=org.apache.kafka.common.config.provider.FileConfigProvider
+
+Next, reference the properties from the file in the connector configuration.
+
+**Example connector configuration referencing file properties**
+
+
+ database.user=${fileProvider:/path/to/connector-credentials.properties:dbUsername}
+ database.password=${fileProvider:/path/to/connector-credentials.properties:dbPassword}
+
+At runtime, the configuration provider reads and extracts the values from the properties file.
diff --git a/docs/documentation/index.html b/docs/configuration/consumer-configs.md
similarity index 75%
copy from docs/documentation/index.html
copy to docs/configuration/consumer-configs.md
index 1d7507f30a9..46334915559 100644
--- a/docs/documentation/index.html
+++ b/docs/configuration/consumer-configs.md
@@ -1,3 +1,13 @@
+---
+title: Consumer Configs
+description: Consumer Configs
+weight: 5
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+Below is the consumer and share consumer configuration: {{< include-html file="/static/42/generated/consumer_config.html" >}}
diff --git a/docs/documentation/index.html b/docs/configuration/group-configs.md
similarity index 77%
copy from docs/documentation/index.html
copy to docs/configuration/group-configs.md
index 1d7507f30a9..bb4db28e43b 100644
--- a/docs/documentation/index.html
+++ b/docs/configuration/group-configs.md
@@ -1,3 +1,13 @@
+---
+title: Group Configs
+description: Group Configs
+weight: 3
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+Below is the group configuration: {{< include-html file="/static/42/generated/group_config.html" >}}
diff --git a/docs/zk2kraft-summary.html b/docs/configuration/kafka-connect-configs.md
similarity index 57%
rename from docs/zk2kraft-summary.html
rename to docs/configuration/kafka-connect-configs.md
index 9ed9c2a5473..c68a0b8ace9 100644
--- a/docs/zk2kraft-summary.html
+++ b/docs/configuration/kafka-connect-configs.md
@@ -1,3 +1,13 @@
+---
+title: Kafka Connect Configs
+description: Kafka Connect Configs
+weight: 6
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,13 +25,13 @@
limitations under the License.
-->
-<script><!--#include virtual="js/templateData.js" --></script>
-<script id="zk2kraft-summary-template" type="text/x-handlebars-template">
-<p>
- There are many differences between ZooKeeper mode and KRaft mode.
- The <a href="/{{version}}/documentation/zk2kraft.html">Differences Between KRaft mode and ZooKeeper mode</a> page lists all of these differences,
- including configurations, metrics, and behavioral changes.
-</p>
-</script>
-<div class="p-zk2kraft-summary"></div>
+Below is the Kafka Connect framework configuration. {{< include-html file="/static/42/generated/connect_config.html" >}}
+
+## Source Connector Configs
+
+Below is the source connector configuration. {{< include-html file="/static/42/generated/source_connector_config.html" >}}
+
+## Sink Connector Configs
+
+Below is the sink connector configuration. {{< include-html file="/static/42/generated/sink_connector_config.html" >}}
diff --git a/docs/documentation/index.html b/docs/configuration/kafka-streams-configs.md
similarity index 74%
copy from docs/documentation/index.html
copy to docs/configuration/kafka-streams-configs.md
index 1d7507f30a9..5522b7a0244 100644
--- a/docs/documentation/index.html
+++ b/docs/configuration/kafka-streams-configs.md
@@ -1,3 +1,13 @@
+---
+title: Kafka Streams Configs
+description: Kafka Streams Configs
+weight: 7
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+Below is the Kafka Streams client library configuration. {{< include-html file="/static/42/generated/streams_config.html" >}}
diff --git a/docs/configuration/mirrormaker-configs.md b/docs/configuration/mirrormaker-configs.md
new file mode 100644
index 00000000000..c2e64fa89b5
--- /dev/null
+++ b/docs/configuration/mirrormaker-configs.md
@@ -0,0 +1,45 @@
+---
+title: MirrorMaker Configs
+description: MirrorMaker Configs
+weight: 9
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Below is the configuration of the connectors that make up MirrorMaker 2.
+
+## MirrorMaker Common Configs
+
+Below is the common configuration that applies to all three connectors. {{< include-html file="/static/42/generated/mirror_connector_config.html" >}}
+
+## MirrorMaker Source Configs
+
+Below is the configuration of MirrorMaker 2 source connector for replicating topics. {{< include-html file="/static/42/generated/mirror_source_config.html" >}}
+
+## MirrorMaker Checkpoint Configs
+
+Below is the configuration of MirrorMaker 2 checkpoint connector for emitting consumer offset checkpoints. {{< include-html file="/static/42/generated/mirror_checkpoint_config.html" >}}
+
+## MirrorMaker HeartBeat Configs
+
+Below is the configuration of MirrorMaker 2 heartbeat connector for checking connectivity between connectors and clusters. {{< include-html file="/static/42/generated/mirror_heartbeat_config.html" >}}
diff --git a/docs/documentation/index.html b/docs/configuration/producer-configs.md
similarity index 76%
copy from docs/documentation/index.html
copy to docs/configuration/producer-configs.md
index 1d7507f30a9..eafba0c9b6d 100644
--- a/docs/documentation/index.html
+++ b/docs/configuration/producer-configs.md
@@ -1,3 +1,13 @@
+---
+title: Producer Configs
+description: Producer Configs
+weight: 4
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+Below is the producer configuration: {{< include-html file="/static/42/generated/producer_config.html" >}}
diff --git a/docs/configuration/system-properties.md b/docs/configuration/system-properties.md
new file mode 100644
index 00000000000..c6296267b13
--- /dev/null
+++ b/docs/configuration/system-properties.md
@@ -0,0 +1,183 @@
+---
+title: System Properties
+description: System Properties
+weight: 10
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Kafka supports some configuration that can be enabled through Java system properties. System properties are usually set by passing the -D flag to the Java virtual machine in which Kafka components are running. Below are the supported system properties.
+
+ * #### org.apache.kafka.sasl.oauthbearer.allowed.files
+
+This system property is used to determine which files, if any, are allowed to be read by the SASL OAUTHBEARER plugin. This property accepts comma-separated list of files. By default the value is an empty list.
+
+If users want to enable some files, users need to explicitly set the system property like below.
+
+ -Dorg.apache.kafka.sasl.oauthbearer.allowed.files=/tmp/token,/tmp/private_key.pem
+
+<table>
+<tr>
+<th>
+
+Since:
+</th>
+<td>
+
+4.1.0
+</td></tr>
+<tr>
+<th>
+
+Default Value:
+</th>
+<td>
+
+
+</td></tr> </table>
+ * #### org.apache.kafka.sasl.oauthbearer.allowed.urls
+
+This system property is used to set the allowed URLs as SASL OAUTHBEARER token or jwks endpoints. This property accepts comma-separated list of URLs. By default the value is an empty list.
+
+If users want to enable some URLs, users need to explicitly set the system property like below.
+
+ -Dorg.apache.kafka.sasl.oauthbearer.allowed.urls=https://www.example.com,file:///tmp/token
+
+<table>
+<tr>
+<th>
+
+Since:
+</th>
+<td>
+
+4.0.0
+</td></tr>
+<tr>
+<th>
+
+Default Value:
+</th>
+<td>
+
+
+</td></tr> </table>
+ * #### org.apache.kafka.disallowed.login.modules
+
+This system property is used to disable the problematic login modules usage in SASL JAAS configuration. This property accepts comma-separated list of loginModule names. By default **com.sun.security.auth.module.JndiLoginModule** and **com.sun.security.auth.module.LdapLoginModule** loginModule is disabled.
+
+If users want to enable JndiLoginModule or LdapLoginModule, users need to explicitly reset the system property like below. We advise the users to validate configurations and only allow trusted JNDI configurations. For more details [CVE-2023-25194](/community/cve-list/#CVE-2023-25194).
+
+ -Dorg.apache.kafka.disallowed.login.modules=
+
+To disable more loginModules, update the system property with comma-separated loginModule names. Make sure to explicitly add **JndiLoginModule** module name to the comma-separated list like below.
+
+ -Dorg.apache.kafka.disallowed.login.modules=com.sun.security.auth.module.JndiLoginModule,com.ibm.security.auth.module.LdapLoginModule,com.ibm.security.auth.module.Krb5LoginModule
+
+The configuration is deprecated and will be removed in a future release. Please use **org.apache.kafka.allowed.login.modules** instead.
+<table>
+<tr>
+<th>
+
+Since:
+</th>
+<td>
+
+3.4.0
+</td></tr>
+<tr>
+<th>
+
+Deprecated:
+</th>
+<td>
+
+4.2.0
+</td></tr>
+<tr>
+<th>
+
+Default Value:
+</th>
+<td>
+
+com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule
+</td></tr> </table>
+ * #### org.apache.kafka.allowed.login.modules
+
+This system property is used to explicitly allow specific login modules in SASL JAAS configuration. It accepts a comma-separated list of login module class names. This property provides a stricter, allowed-list-based alternative to the deprecated `org.apache.kafka.disallowed.login.modules` property. It is recommended to use this property to improve the security of JAAS configurations.
+
+If both properties are set, `org.apache.kafka.allowed.login.modules` takes precedence.
+
+<table>
+<tr>
+<th>
+
+Since:
+</th>
+<td>
+
+4.2.0
+</td></tr>
+<tr>
+<th>
+
+Default Value:
+</th></tr> </table>
+ * #### org.apache.kafka.automatic.config.providers
+
+This system property controls the automatic loading of ConfigProvider implementations in Apache Kafka. ConfigProviders are used to dynamically supply configuration values from sources such as files, directories, or environment variables. This property accepts a comma-separated list of ConfigProvider names. By default, all built-in ConfigProviders are enabled, including **FileConfigProvider** , **DirectoryConfigProvider** , and **EnvVarConfigProvider**.
+
+If users want to disable all automatic ConfigProviders, they need to explicitly set the system property as shown below. Disabling automatic ConfigProviders is recommended in environments where configuration data comes from untrusted sources or where increased security is required. For more details, see [CVE-2024-31141](/community/cve-list/#CVE-2024-31141).
+
+ -Dorg.apache.kafka.automatic.config.providers=none
+
+To allow specific ConfigProviders, update the system property with a comma-separated list of fully qualified ConfigProvider class names. For example, to enable only the **EnvVarConfigProvider** , set the property as follows:
+
+ -Dorg.apache.kafka.automatic.config.providers=org.apache.kafka.common.config.provider.EnvVarConfigProvider
+
+To use multiple ConfigProviders, include their names in a comma-separated list as shown below:
+
+ -Dorg.apache.kafka.automatic.config.providers=org.apache.kafka.common.config.provider.FileConfigProvider,org.apache.kafka.common.config.provider.EnvVarConfigProvider
+
+<table>
+<tr>
+<th>
+
+Since:
+</th>
+<td>
+
+3.8.0
+</td></tr>
+<tr>
+<th>
+
+Default Value:
+</th>
+<td>
+
+All built-in ConfigProviders are enabled
+</td></tr> </table>
+
+
diff --git a/docs/configuration/tiered-storage-configs.md b/docs/configuration/tiered-storage-configs.md
new file mode 100644
index 00000000000..60c735a2e68
--- /dev/null
+++ b/docs/configuration/tiered-storage-configs.md
@@ -0,0 +1,51 @@
+---
+title: Tiered Storage Configs
+description: Tiered Storage Configs
+weight: 11
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Below is the Tiered Storage configuration. {{< include-html file="/static/42/generated/remote_log_manager_config.html" >}}
+
+## RLMM Configs
+
+Below is the configuration for `TopicBasedRemoteLogMetadataManager`, which is the default implementation of `RemoteLogMetadataManager`.
+
+All configurations here should start with the prefix defined by `remote.log.metadata.manager.impl.prefix`, for example, `rlmm.config.remote.log.metadata.consume.wait.ms`.
+
+{{< include-html file="/static/42/generated/remote_log_metadata_manager_config.html" >}}
+
+The implementation of `TopicBasedRemoteLogMetadataManager` needs to create admin, producer, and consumer clients for the internal topic `__remote_log_metadata`.
+
+Additional configurations can be provided for different types of clients using the following configuration properties:
+
+
+ # Configs for admin, producer, and consumer clients
+ <rlmm.prefix>.remote.log.metadata.common.client.<kafka.property> = <value>
+
+ # Configs only for producer client
+ <rlmm.prefix>.remote.log.metadata.producer.<kafka.property> = <value>
+
+ # Configs only for consumer client
+ <rlmm.prefix>.remote.log.metadata.consumer.<kafka.property> = <value>
diff --git a/docs/configuration/topic-configs.md b/docs/configuration/topic-configs.md
new file mode 100644
index 00000000000..3e77b39ba0f
--- /dev/null
+++ b/docs/configuration/topic-configs.md
@@ -0,0 +1,52 @@
+---
+title: Topic Configs
+description: Topic Configs
+weight: 2
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Configurations pertinent to topics have both a server default as well an optional per-topic override. If no per-topic configuration is given the server default is used. The override can be set at topic creation time by giving one or more `--config` options. This example creates a topic named _my-topic_ with a custom max message size and flush rate:
+
+
+ $ bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-topic --partitions 1 \
+ --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1
+
+Overrides can also be changed or set later using the alter configs command. This example updates the max message size for _my-topic_ :
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
+ --alter --add-config max.message.bytes=128000
+
+To check overrides set on the topic you can do
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe
+
+To remove an override you can do
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic
+ --alter --delete-config max.message.bytes
+
+Below is the topic configuration. The server's default configuration for this property is given under the Server Default Property heading. A given server default config value only applies to a topic if it does not have an explicit topic config override. {{< include-html file="/static/42/generated/topic_config.html" >}}
diff --git a/docs/connect.html b/docs/connect.html
deleted file mode 100644
index 847f55bd398..00000000000
--- a/docs/connect.html
+++ /dev/null
@@ -1,1060 +0,0 @@
-<!--~
- ~ Licensed to the Apache Software Foundation (ASF) under one or more
- ~ contributor license agreements. See the NOTICE file distributed with
- ~ this work for additional information regarding copyright ownership.
- ~ The ASF licenses this file to You under the Apache License, Version 2.0
- ~ (the "License"); you may not use this file except in compliance with
- ~ the License. You may obtain a copy of the License at
- ~
- ~ http://www.apache.org/licenses/LICENSE-2.0
- ~
- ~ Unless required by applicable law or agreed to in writing, software
- ~ distributed under the License is distributed on an "AS IS" BASIS,
- ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- ~ See the License for the specific language governing permissions and
- ~ limitations under the License.
- ~-->
-
-<script id="connect-template" type="text/x-handlebars-template">
- <h3><a id="connect_overview" href="#connect_overview">8.1 Overview</a></h3>
-
- <p>Kafka Connect is a tool for scalably and reliably streaming data between Apache Kafka and other systems. It makes it simple to quickly define <i>connectors</i> that move large collections of data into and out of Kafka. Kafka Connect can ingest entire databases or collect metrics from all your application servers into Kafka topics, making the data available for stream processing with low latency. An export job can deliver data from Kafka topics into secondary storage and query syst [...]
-
- <p>Kafka Connect features include:</p>
- <ul>
- <li><b>A common framework for Kafka connectors</b> - Kafka Connect standardizes integration of other data systems with Kafka, simplifying connector development, deployment, and management</li>
- <li><b>Distributed and standalone modes</b> - scale up to a large, centrally managed service supporting an entire organization or scale down to development, testing, and small production deployments</li>
- <li><b>REST interface</b> - submit and manage connectors to your Kafka Connect cluster via an easy to use REST API</li>
- <li><b>Automatic offset management</b> - with just a little information from connectors, Kafka Connect can manage the offset commit process automatically so connector developers do not need to worry about this error prone part of connector development</li>
- <li><b>Distributed and scalable by default</b> - Kafka Connect builds on the existing group management protocol. More workers can be added to scale up a Kafka Connect cluster.</li>
- <li><b>Streaming/batch integration</b> - leveraging Kafka's existing capabilities, Kafka Connect is an ideal solution for bridging streaming and batch data systems</li>
- </ul>
-
- <h3><a id="connect_user" href="#connect_user">8.2 User Guide</a></h3>
-
- <p>The <a href="../quickstart">quickstart</a> provides a brief example of how to run a standalone version of Kafka Connect. This section describes how to configure, run, and manage Kafka Connect in more detail.</p>
-
- <h4><a id="connect_running" href="#connect_running">Running Kafka Connect</a></h4>
-
- <p>Kafka Connect currently supports two modes of execution: standalone (single process) and distributed.</p>
-
- <p>In standalone mode all work is performed in a single process. This configuration is simpler to setup and get started with and may be useful in situations where only one worker makes sense (e.g. collecting log files), but it does not benefit from some of the features of Kafka Connect such as fault tolerance. You can start a standalone process with the following command:</p>
-
- <pre><code class="language-bash">$ bin/connect-standalone.sh config/connect-standalone.properties [connector1.properties connector2.json …]</code></pre>
-
- <p>The first parameter is the configuration for the worker. This includes settings such as the Kafka connection parameters, serialization format, and how frequently to commit offsets. The provided example should work well with a local cluster running with the default configuration provided by <code>config/server.properties</code>. It will require tweaking to use with a different configuration or production deployment. All workers (both standalone and distributed) require a few configs:</p>
- <ul>
- <li><code>bootstrap.servers</code> - List of Kafka servers used to bootstrap connections to Kafka</li>
- <li><code>key.converter</code> - Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the keys in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.</li>
- <li><code>value.converter</code> - Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the values in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.</li>
- <li><code>plugin.path</code> (default <code>null</code>) - a list of paths that contain Connect plugins (connectors, converters, transformations). Before running quick starts, users must add the absolute path that contains the example FileStreamSourceConnector and FileStreamSinkConnector packaged in <code>connect-file-{{fullDotVersion}}.jar</code>, because these connectors are not included by default to the <code>CLASSPATH</code> or the <code>plugin.path</code> of the Connect wor [...]
- </ul>
-
- <p>The important configuration options specific to standalone mode are:</p>
- <ul>
- <li><code>offset.storage.file.filename</code> - File to store source connector offsets</li>
- </ul>
-
- <p>The parameters that are configured here are intended for producers and consumers used by Kafka Connect to access the configuration, offset and status topics. For configuration of the producers used by Kafka source tasks and the consumers used by Kafka sink tasks, the same parameters can be used but need to be prefixed with <code>producer.</code> and <code>consumer.</code> respectively. The only Kafka client parameter that is inherited without a prefix from the worker configuration [...]
-
- <p>Client configuration overrides can be configured individually per connector by using the prefixes <code>producer.override.</code> and <code>consumer.override.</code> for Kafka sources or Kafka sinks respectively. These overrides are included with the rest of the connector's configuration properties.</p>
-
- <p>The remaining parameters are connector configuration files. Each file may either be a Java Properties file or a JSON file containing an object with the same structure as the request body of either the <code>POST /connectors</code> endpoint or the <code>PUT /connectors/{name}/config</code> endpoint (see the <a href="/{{version}}/generated/connect_rest.yaml">OpenAPI documentation</a>). You may include as many as you want, but all will execute within the same process (on different th [...]
-
- <p>Distributed mode handles automatic balancing of work, allows you to scale up (or down) dynamically, and offers fault tolerance both in the active tasks and for configuration and offset commit data. Execution is very similar to standalone mode:</p>
-
- <pre><code class="language-bash">$ bin/connect-distributed.sh config/connect-distributed.properties</code></pre>
-
- <p>The difference is in the class which is started and the configuration parameters which change how the Kafka Connect process decides where to store configurations, how to assign work, and where to store offsets and task statues. In the distributed mode, Kafka Connect stores the offsets, configs and task statuses in Kafka topics. It is recommended to manually create the topics for offset, configs and statuses in order to achieve the desired the number of partitions and replication f [...]
-
- <p>In particular, the following configuration parameters, in addition to the common settings mentioned above, are critical to set before starting your cluster:</p>
- <ul>
- <li><code>group.id</code> - Unique name for the cluster, used in forming the Connect cluster group; note that this <b>must not conflict</b> with consumer group IDs</li>
- <li><code>config.storage.topic</code> - Name for the topic to use for storing connector and task configurations; this topic should have a single partition, be replicated, and be configured for compaction</li>
- <li><code>offset.storage.topic</code> - Name for the topic to use for storing offsets; this topic should have many partitions, be replicated, and be configured for compaction</li>
- <li><code>status.storage.topic</code> - Name for the topic to use for storing statuses; this topic can have multiple partitions, be replicated, and be configured for compaction</li>
- </ul>
-
- <p>Note that in distributed mode the connector configurations are not passed on the command line. Instead, use the REST API described below to create, modify, and destroy connectors.</p>
-
-
- <h4><a id="connect_configuring" href="#connect_configuring">Configuring Connectors</a></h4>
-
- <p>Connector configurations are simple key-value mappings. In both standalone and distributed mode, they are included in the JSON payload for the REST request that creates (or modifies) the connector. In standalone mode these can also be defined in a properties file and passed to the Connect process on the command line.</p>
-
- <p>Most configurations are connector dependent, so they can't be outlined here. However, there are a few common options:</p>
-
- <ul>
- <li><code>name</code> - Unique name for the connector. Attempting to register again with the same name will fail.</li>
- <li><code>connector.class</code> - The Java class for the connector</li>
- <li><code>tasks.max</code> - The maximum number of tasks that should be created for this connector. The connector may create fewer tasks if it cannot achieve this level of parallelism.</li>
- <li><code>key.converter</code> - (optional) Override the default key converter set by the worker.</li>
- <li><code>value.converter</code> - (optional) Override the default value converter set by the worker.</li>
- </ul>
-
- <p>The <code>connector.class</code> config supports several formats: the full name or alias of the class for this connector. If the connector is org.apache.kafka.connect.file.FileStreamSinkConnector, you can either specify this full name or use FileStreamSink or FileStreamSinkConnector to make the configuration a bit shorter.</p>
-
- <p>Sink connectors also have a few additional options to control their input. Each sink connector must set one of the following:</p>
- <ul>
- <li><code>topics</code> - A comma-separated list of topics to use as input for this connector</li>
- <li><code>topics.regex</code> - A Java regular expression of topics to use as input for this connector</li>
- </ul>
-
- <p>For any other options, you should consult the documentation for the connector.</p>
-
- <h4><a id="connect_transforms" href="#connect_transforms">Transformations</a></h4>
-
- <p>Connectors can be configured with transformations to make lightweight message-at-a-time modifications. They can be convenient for data massaging and event routing.</p>
-
- <p>A transformation chain can be specified in the connector configuration.</p>
-
- <ul>
- <li><code>transforms</code> - List of aliases for the transformation, specifying the order in which the transformations will be applied.</li>
- <li><code>transforms.$alias.type</code> - Fully qualified class name for the transformation.</li>
- <li><code>transforms.$alias.$transformationSpecificConfig</code> Configuration properties for the transformation</li>
- </ul>
-
- <p>For example, lets take the built-in file source connector and use a transformation to add a static field.</p>
-
- <p>Throughout the example we'll use schemaless JSON data format. To use schemaless format, we changed the following two lines in <code>connect-standalone.properties</code> from true to false:</p>
-
- <pre><code class="language-text">key.converter.schemas.enable
-value.converter.schemas.enable</code></pre>
-
- <p>The file source connector reads each line as a String. We will wrap each line in a Map and then add a second field to identify the origin of the event. To do this, we use two transformations:</p>
- <ul>
- <li><b>HoistField</b> to place the input line inside a Map</li>
- <li><b>InsertField</b> to add the static field. In this example we'll indicate that the record came from a file connector</li>
- </ul>
-
- <p>After adding the transformations, <code>connect-file-source.properties</code> file looks as following:</p>
-
- <pre><code class="language-text">name=local-file-source
-connector.class=FileStreamSource
-tasks.max=1
-file=test.txt
-topic=connect-test
-transforms=MakeMap, InsertSource
-transforms.MakeMap.type=org.apache.kafka.connect.transforms.HoistField$Value
-transforms.MakeMap.field=line
-transforms.InsertSource.type=org.apache.kafka.connect.transforms.InsertField$Value
-transforms.InsertSource.static.field=data_source
-transforms.InsertSource.static.value=test-file-source</code></pre>
-
- <p>All the lines starting with <code>transforms</code> were added for the transformations. You can see the two transformations we created: "InsertSource" and "MakeMap" are aliases that we chose to give the transformations. The transformation types are based on the list of built-in transformations you can see below. Each transformation type has additional configuration: HoistField requires a configuration called "field", which is the name of the field in the map that will include the [...]
-
- <p>When we ran the file source connector on my sample file without the transformations, and then read them using <code>kafka-console-consumer.sh</code>, the results were:</p>
-
- <pre><code class="language-text">"foo"
-"bar"
-"hello world"</code></pre>
-
- <p>We then create a new file connector, this time after adding the transformations to the configuration file. This time, the results will be:</p>
-
- <pre><code class="language-json">{"line":"foo","data_source":"test-file-source"}
-{"line":"bar","data_source":"test-file-source"}
-{"line":"hello world","data_source":"test-file-source"}</code></pre>
-
- <p>You can see that the lines we've read are now part of a JSON map, and there is an extra field with the static value we specified. This is just one example of what you can do with transformations.</p>
-
- <h5><a id="connect_included_transformation" href="#connect_included_transformation">Included transformations</a></h5>
-
- <p>Several widely-applicable data and routing transformations are included with Kafka Connect:</p>
-
- <ul>
- <li><a href="#org.apache.kafka.connect.transforms.Cast">Cast</a> - Cast fields or the entire key or value to a specific type</li>
- <li><a href="#org.apache.kafka.connect.transforms.DropHeaders">DropHeaders</a> - Remove headers by name</li>
- <li><a href="#org.apache.kafka.connect.transforms.ExtractField">ExtractField</a> - Extract a specific field from Struct and Map and include only this field in results</li>
- <li><a href="#org.apache.kafka.connect.transforms.Filter">Filter</a> - Removes messages from all further processing. This is used with a <a href="#connect_predicates">predicate</a> to selectively filter certain messages</li>
- <li><a href="#org.apache.kafka.connect.transforms.Flatten">Flatten</a> - Flatten a nested data structure</li>
- <li><a href="#org.apache.kafka.connect.transforms.HeaderFrom">HeaderFrom</a> - Copy or move fields in the key or value to the record headers</li>
- <li><a href="#org.apache.kafka.connect.transforms.HoistField">HoistField</a> - Wrap the entire event as a single field inside a Struct or a Map</li>
- <li><a href="#org.apache.kafka.connect.transforms.InsertField">InsertField</a> - Add a field using either static data or record metadata</li>
- <li><a href="#org.apache.kafka.connect.transforms.InsertHeader">InsertHeader</a> - Add a header using static data</li>
- <li><a href="#org.apache.kafka.connect.transforms.MaskField">MaskField</a> - Replace field with valid null value for the type (0, empty string, etc) or custom replacement (non-empty string or numeric value only)</li>
- <li><a href="#org.apache.kafka.connect.transforms.RegexRouter">RegexRouter</a> - modify the topic of a record based on original topic, replacement string and a regular expression</li>
- <li><a href="#org.apache.kafka.connect.transforms.ReplaceField">ReplaceField</a> - Filter or rename fields</li>
- <li><a href="#org.apache.kafka.connect.transforms.SetSchemaMetadata">SetSchemaMetadata</a> - modify the schema name or version</li>
- <li><a href="#org.apache.kafka.connect.transforms.TimestampConverter">TimestampConverter</a> - Convert timestamps between different formats</li>
- <li><a href="#org.apache.kafka.connect.transforms.TimestampRouter">TimestampRouter</a> - Modify the topic of a record based on original topic and timestamp. Useful when using a sink that needs to write to different tables or indexes based on timestamps</li>
- <li><a href="#org.apache.kafka.connect.transforms.ValueToKey">ValueToKey</a> - Replace the record key with a new key formed from a subset of fields in the record value</li>
- </ul>
-
- <p>Details on how to configure each transformation are listed below:</p>
-
-
- <!--#include virtual="generated/connect_transforms.html" -->
-
-
- <h5><a id="connect_predicates" href="#connect_predicates">Predicates</a></h5>
-
- <p>Transformations can be configured with predicates so that the transformation is applied only to messages which satisfy some condition. In particular, when combined with the <b>Filter</b> transformation predicates can be used to selectively filter out certain messages.</p>
-
- <p>Predicates are specified in the connector configuration.</p>
-
- <ul>
- <li><code>predicates</code> - Set of aliases for the predicates to be applied to some of the transformations.</li>
- <li><code>predicates.$alias.type</code> - Fully qualified class name for the predicate.</li>
- <li><code>predicates.$alias.$predicateSpecificConfig</code> - Configuration properties for the predicate.</li>
- </ul>
-
- <p>All transformations have the implicit config properties <code>predicate</code> and <code>negate</code>. A predicular predicate is associated with a transformation by setting the transformation's <code>predicate</code> config to the predicate's alias. The predicate's value can be reversed using the <code>negate</code> configuration property.</p>
-
- <p>For example, suppose you have a source connector which produces messages to many different topics and you want to:</p>
- <ul>
- <li>filter out the messages in the 'foo' topic entirely</li>
- <li>apply the ExtractField transformation with the field name 'other_field' to records in all topics <i>except</i> the topic 'bar'</li>
- </ul>
-
- <p>To do this we need first to filter out the records destined for the topic 'foo'. The Filter transformation removes records from further processing, and can use the TopicNameMatches predicate to apply the transformation only to records in topics which match a certain regular expression. TopicNameMatches's only configuration property is <code>pattern</code> which is a Java regular expression for matching against the topic name. The configuration would look like this:</p>
-
- <pre><code class="language-text">transforms=Filter
-transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
-transforms.Filter.predicate=IsFoo
-
-predicates=IsFoo
-predicates.IsFoo.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
-predicates.IsFoo.pattern=foo</code></pre>
-
- <p>Next we need to apply ExtractField only when the topic name of the record is not 'bar'. We can't just use TopicNameMatches directly, because that would apply the transformation to matching topic names, not topic names which do <i>not</i> match. The transformation's implicit <code>negate</code> config properties allows us to invert the set of records which a predicate matches. Adding the configuration for this to the previous example we arrive at:</p>
-
- <pre><code class="language-text">transforms=Filter,Extract
-transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
-transforms.Filter.predicate=IsFoo
-
-transforms.Extract.type=org.apache.kafka.connect.transforms.ExtractField$Key
-transforms.Extract.field=other_field
-transforms.Extract.predicate=IsBar
-transforms.Extract.negate=true
-
-predicates=IsFoo,IsBar
-predicates.IsFoo.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
-predicates.IsFoo.pattern=foo
-
-predicates.IsBar.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
-predicates.IsBar.pattern=bar</code></pre>
-
- <p>Kafka Connect includes the following predicates:</p>
-
- <ul>
- <li><code>TopicNameMatches</code> - matches records in a topic with a name matching a particular Java regular expression.</li>
- <li><code>HasHeaderKey</code> - matches records which have a header with the given key.</li>
- <li><code>RecordIsTombstone</code> - matches tombstone records, that is records with a null value.</li>
- </ul>
-
- <p>Details on how to configure each predicate are listed below:</p>
-
- <!--#include virtual="generated/connect_predicates.html" -->
-
-
- <h4><a id="connect_rest" href="#connect_rest">REST API</a></h4>
-
- <p>Since Kafka Connect is intended to be run as a service, it also provides a REST API for managing connectors. This REST API is available in both standalone and distributed mode. The REST API server can be configured using the <code>listeners</code> configuration option.
- This field should contain a list of listeners in the following format: <code>protocol://host:port,protocol2://host2:port2</code>. Currently supported protocols are <code>http</code> and <code>https</code>.
- For example:</p>
-
- <pre><code class="language-text">listeners=http://localhost:8080,https://localhost:8443</code></pre>
-
- <p>By default, if no <code>listeners</code> are specified, the REST server runs on port 8083 using the HTTP protocol. When using HTTPS, the configuration has to include the SSL configuration.
- By default, it will use the <code>ssl.*</code> settings. In case it is needed to use different configuration for the REST API than for connecting to Kafka brokers, the fields can be prefixed with <code>listeners.https</code>.
- When using the prefix, only the prefixed options will be used and the <code>ssl.*</code> options without the prefix will be ignored. Following fields can be used to configure HTTPS for the REST API:</p>
-
- <ul>
- <li><code>ssl.keystore.location</code></li>
- <li><code>ssl.keystore.password</code></li>
- <li><code>ssl.keystore.type</code></li>
- <li><code>ssl.key.password</code></li>
- <li><code>ssl.truststore.location</code></li>
- <li><code>ssl.truststore.password</code></li>
- <li><code>ssl.truststore.type</code></li>
- <li><code>ssl.enabled.protocols</code></li>
- <li><code>ssl.provider</code></li>
- <li><code>ssl.protocol</code></li>
- <li><code>ssl.cipher.suites</code></li>
- <li><code>ssl.keymanager.algorithm</code></li>
- <li><code>ssl.secure.random.implementation</code></li>
- <li><code>ssl.trustmanager.algorithm</code></li>
- <li><code>ssl.endpoint.identification.algorithm</code></li>
- <li><code>ssl.client.auth</code></li>
- </ul>
-
- <p>The REST API is used not only by users to monitor / manage Kafka Connect. In distributed mode, it is also used for the Kafka Connect cross-cluster communication. Some requests received on the follower nodes REST API will be forwarded to the leader node REST API.
- In case the URI under which is given host reachable is different from the URI which it listens on, the configuration options <code>rest.advertised.host.name</code>, <code>rest.advertised.port</code> and <code>rest.advertised.listener</code>
- can be used to change the URI which will be used by the follower nodes to connect with the leader. When using both HTTP and HTTPS listeners, the <code>rest.advertised.listener</code> option can be also used to define which listener
- will be used for the cross-cluster communication. When using HTTPS for communication between nodes, the same <code>ssl.*</code> or <code>listeners.https</code> options will be used to configure the HTTPS client.</p>
-
- <p>The following are the currently supported REST API endpoints:</p>
-
- <ul>
- <li><code>GET /connectors</code> - return a list of active connectors</li>
- <li><code>POST /connectors</code> - create a new connector; the request body should be a JSON object containing a string <code>name</code> field and an object <code>config</code> field with the connector configuration parameters. The JSON object may also optionally contain a string <code>initial_state</code> field which can take the following values - <code>STOPPED</code>, <code>PAUSED</code> or <code>RUNNING</code> (the default value)</li>
- <li><code>GET /connectors/{name}</code> - get information about a specific connector</li>
- <li><code>GET /connectors/{name}/config</code> - get the configuration parameters for a specific connector</li>
- <li><code>PUT /connectors/{name}/config</code> - update the configuration parameters for a specific connector</li>
- <li><code>PATCH /connectors/{name}/config</code> - patch the configuration parameters for a specific connector, where <code>null</code> values in the JSON body indicates removing of the key from the final configuration</li>
- <li><code>GET /connectors/{name}/status</code> - get current status of the connector, including if it is running, failed, paused, etc., which worker it is assigned to, error information if it has failed, and the state of all its tasks</li>
- <li><code>GET /connectors/{name}/tasks</code> - get a list of tasks currently running for a connector along with their configurations</li>
- <li><code>GET /connectors/{name}/tasks/{taskid}/status</code> - get current status of the task, including if it is running, failed, paused, etc., which worker it is assigned to, and error information if it has failed</li>
- <li><code>PUT /connectors/{name}/pause</code> - pause the connector and its tasks, which stops message processing until the connector is resumed. Any resources claimed by its tasks are left allocated, which allows the connector to begin processing data quickly once it is resumed.</li>
- <li id="connect_stopconnector"><code>PUT /connectors/{name}/stop</code> - stop the connector and shut down its tasks, deallocating any resources claimed by its tasks. This is more efficient from a resource usage standpoint than pausing the connector, but can cause it to take longer to begin processing data once resumed. Note that the offsets for a connector can be only modified via the offsets management endpoints if it is in the stopped state</li>
- <li><code>PUT /connectors/{name}/resume</code> - resume a paused or stopped connector (or do nothing if the connector is not paused or stopped)</li>
- <li><code>POST /connectors/{name}/restart?includeTasks=<true|false>&onlyFailed=<true|false></code> - restart a connector and its tasks instances.
- <ul>
- <li>the "includeTasks" parameter specifies whether to restart the connector instance and task instances ("includeTasks=true") or just the connector instance ("includeTasks=false"), with the default ("false") preserving the same behavior as earlier versions.</li>
- <li>the "onlyFailed" parameter specifies whether to restart just the instances with a FAILED status ("onlyFailed=true") or all instances ("onlyFailed=false"), with the default ("false") preserving the same behavior as earlier versions.</li>
- </ul>
- </li>
- <li><code>POST /connectors/{name}/tasks/{taskId}/restart</code> - restart an individual task (typically because it has failed)</li>
- <li><code>DELETE /connectors/{name}</code> - delete a connector, halting all tasks and deleting its configuration</li>
- <li><code>GET /connectors/{name}/topics</code> - get the set of topics that a specific connector is using since the connector was created or since a request to reset its set of active topics was issued</li>
- <li><code>PUT /connectors/{name}/topics/reset</code> - send a request to empty the set of active topics of a connector</li>
- <li>Offsets management endpoints (see <a href="https://cwiki.apache.org/confluence/x/Io3GDQ">KIP-875</a> for more details):
- <ul>
- <li><code>GET /connectors/{name}/offsets</code> - get the current offsets for a connector</li>
- <li><code>DELETE /connectors/{name}/offsets</code> - reset the offsets for a connector. The connector must exist and must be in the stopped state (see <a href="#connect_stopconnector"><code>PUT /connectors/{name}/stop</code></a>)</li>
- <li><code>PATCH /connectors/{name}/offsets</code> - alter the offsets for a connector. The connector must exist and must be in the stopped state (see <a href="#connect_stopconnector"><code>PUT /connectors/{name}/stop</code></a>). The request body should be a JSON object containing a JSON array <code>offsets</code> field, similar to the response body of the <code>GET /connectors/{name}/offsets</code> endpoint.
- An example request body for the <code>FileStreamSourceConnector</code>:
- <pre><code class="language-json">{
- "offsets": [
- {
- "partition": {
- "filename": "test.txt"
- },
- "offset": {
- "position": 30
- }
- }
- ]
-}</code></pre>
- An example request body for the <code>FileStreamSinkConnector</code>:
- <pre><code class="language-json">{
- "offsets": [
- {
- "partition": {
- "kafka_topic": "test",
- "kafka_partition": 0
- },
- "offset": {
- "kafka_offset": 5
- }
- },
- {
- "partition": {
- "kafka_topic": "test",
- "kafka_partition": 1
- },
- "offset": null
- }
- ]
-}</code></pre>
- The "offset" field may be null to reset the offset for a specific partition (applicable to both source and sink connectors). Note that the request body format depends on the connector implementation in the case of source connectors, whereas there is a common format across all sink connectors.</li>
- </ul>
- </li>
- </ul>
-
- <p>Kafka Connect also provides a REST API for getting information about connector plugins:</p>
-
- <ul>
- <li><code>GET /connector-plugins</code>- return a list of connector plugins installed in the Kafka Connect cluster. Note that the API only checks for connectors on the worker that handles the request, which means you may see inconsistent results, especially during a rolling upgrade if you add new connector jars</li>
- <li><code>GET /connector-plugins/{plugin-type}/config</code> - get the configuration definition for the specified plugin.</li>
- <li><code>PUT /connector-plugins/{connector-type}/config/validate</code> - validate the provided configuration values against the configuration definition. This API performs per config validation, returns suggested values and error messages during validation.</li>
- </ul>
-
- <p>The following is a supported REST request at the top-level (root) endpoint:</p>
-
- <ul>
- <li><code>GET /</code>- return basic information about the Kafka Connect cluster such as the version of the Connect worker that serves the REST request (including git commit ID of the source code) and the Kafka cluster ID that is connected to.
- </ul>
-
- <p>The <code>admin.listeners</code> configuration can be used to configure admin REST APIs on Kafka Connect's REST API server. Similar to the <code>listeners</code> configuration, this field should contain a list of listeners in the following format: <code>protocol://host:port,protocol2://host2:port2</code>. Currently supported protocols are <code>http</code> and <code>https</code>.
- For example:</p>
-
- <pre><code class="language-text">admin.listeners=http://localhost:8080,https://localhost:8443</code></pre>
-
- <p>By default, if <code>admin.listeners</code> is not configured, the admin REST APIs will be available on the regular listeners.</p>
-
- <p>The following are the currently supported admin REST API endpoints:</p>
-
- <ul>
- <li><code>GET /admin/loggers</code> - list the current loggers that have their levels explicitly set and their log levels</li>
- <li><code>GET /admin/loggers/{name}</code> - get the log level for the specified logger</li>
- <li><code>PUT /admin/loggers/{name}</code> - set the log level for the specified logger</li>
- </ul>
-
- <p>See <a href="https://cwiki.apache.org/confluence/x/-4tTBw">KIP-495</a> for more details about the admin logger REST APIs.</p>
-
- <p>For the complete specification of the Kafka Connect REST API, see the <a href="/{{version}}/generated/connect_rest.yaml">OpenAPI documentation</a></p>
-
- <h4><a id="connect_errorreporting" href="#connect_errorreporting">Error Reporting in Connect</a></h4>
-
- <p>Kafka Connect provides error reporting to handle errors encountered along various stages of processing. By default, any error encountered during conversion or within transformations will cause the connector to fail. Each connector configuration can also enable tolerating such errors by skipping them, optionally writing each error and the details of the failed operation and problematic record (with various levels of detail) to the Connect application log. These mechanisms also capt [...]
-
- <p>To report errors within a connector's converter, transforms, or within the sink connector itself to the log, set <code>errors.log.enable=true</code> in the connector configuration to log details of each error and problem record's topic, partition, and offset. For additional debugging purposes, set <code>errors.log.include.messages=true</code> to also log the problem record key, value, and headers to the log (note this may log sensitive information).</p>
-
- <p>To report errors within a connector's converter, transforms, or within the sink connector itself to a dead letter queue topic, set <code>errors.deadletterqueue.topic.name</code>, and optionally <code>errors.deadletterqueue.context.headers.enable=true</code>.</p>
-
- <p>By default connectors exhibit "fail fast" behavior immediately upon an error or exception. This is equivalent to adding the following configuration properties with their defaults to a connector configuration:</p>
-
- <pre><code class="language-text"># disable retries on failure
-errors.retry.timeout=0
-
-# do not log the error and their contexts
-errors.log.enable=false
-
-# do not record errors in a dead letter queue topic
-errors.deadletterqueue.topic.name=
-
-# Fail on first error
-errors.tolerance=none</code></pre>
-
- <p>These and other related connector configuration properties can be changed to provide different behavior. For example, the following configuration properties can be added to a connector configuration to setup error handling with multiple retries, logging to the application logs and the <code>my-connector-errors</code> Kafka topic, and tolerating all errors by reporting them rather than failing the connector task:</p>
-
- <pre><code class="language-text"># retry for at most 10 minutes times waiting up to 30 seconds between consecutive failures
-errors.retry.timeout=600000
-errors.retry.delay.max.ms=30000
-
-# log error context along with application logs, but do not include configs and messages
-errors.log.enable=true
-errors.log.include.messages=false
-
-# produce error context into the Kafka topic
-errors.deadletterqueue.topic.name=my-connector-errors
-
-# Tolerate all errors.
-errors.tolerance=all</code></pre>
-
- <h4><a id="connect_exactlyonce" href="#connect_exactlyonce">Exactly-once support</a></h4>
-
- <p>Kafka Connect is capable of providing exactly-once semantics for sink connectors (as of version 0.11.0) and source connectors (as of version 3.3.0). Please note that <b>support for exactly-once semantics is highly dependent on the type of connector you run.</b> Even if you set all the correct worker properties in the configuration for each node in a cluster, if a connector is not designed to, or cannot take advantage of the capabilities of the Kafka Connect framework, exactly-once [...]
-
- <h5><a id="connect_exactlyoncesink" href="#connect_exactlyoncesink">Sink connectors</a></h5>
-
- <p>If a sink connector supports exactly-once semantics, to enable exactly-once at the Connect worker level, you must ensure its consumer group is configured to ignore records in aborted transactions. You can do this by setting the worker property <code>consumer.isolation.level</code> to <code>read_committed</code> or, if running a version of Kafka Connect that supports it, using a <a href="#connectconfigs_connector.client.config.override.policy">connector client config override polic [...]
-
- <h5><a id="connect_exactlyoncesource" href="#connect_exactlyoncesource">Source connectors</a></h5>
-
- <p>If a source connector supports exactly-once semantics, you must configure your Connect cluster to enable framework-level support for exactly-once source connectors. Additional ACLs may be necessary if running against a secured Kafka cluster. Note that exactly-once support for source connectors is currently only available in distributed mode; standalone Connect workers cannot provide exactly-once semantics.</p>
-
- <h6>Worker configuration</h6>
-
- <p>For new Connect clusters, set the <code>exactly.once.source.support</code> property to <code>enabled</code> in the worker config for each node in the cluster. For existing clusters, two rolling upgrades are necessary. During the first upgrade, the <code>exactly.once.source.support</code> property should be set to <code>preparing</code>, and during the second, it should be set to <code>enabled</code>.</p>
-
- <h6>ACL requirements</h6>
-
- <p>With exactly-once source support enabled, or with <code>exactly.once.source.support</code> set to <code>preparing</code>, the principal for each Connect worker will require the following ACLs:</p>
-
- <table class="data-table">
- <thead>
- <tr>
- <th>Operation</th>
- <th>Resource Type</th>
- <th>Resource Name</th>
- <th>Note</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>Write</td>
- <td>TransactionalId</td>
- <td><code>connect-cluster-${groupId}</code>, where <code>${groupId}</code> is the <code>group.id</code> of the cluster</td>
- <td></td>
- </tr>
- <tr>
- <td>Describe</td>
- <td>TransactionalId</td>
- <td><code>connect-cluster-${groupId}</code>, where <code>${groupId}</code> is the <code>group.id</code> of the cluster</td>
- <td></td>
- </tr>
- <tr>
- <td>IdempotentWrite</td>
- <td>Cluster</td>
- <td>ID of the Kafka cluster that hosts the worker's config topic</td>
- <td>The IdempotentWrite ACL has been deprecated as of 2.8 and will only be necessary for Connect clusters running on pre-2.8 Kafka clusters</td>
- </tr>
- </tbody>
- </table>
-
- <p>And with exactly-once source enabled (but not if <code>exactly.once.source.support</code> is set to <code>preparing</code>), the principal for each individual connector will require the following ACLs:</p>
-
- <table class="data-table">
- <thead>
- <tr>
- <th>Operation</th>
- <th>Resource Type</th>
- <th>Resource Name</th>
- <th>Note</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>Write</td>
- <td>TransactionalId</td>
- <td><code>${groupId}-${connector}-${taskId}</code>, for each task that the connector will create, where <code>${groupId}</code> is the <code>group.id</code> of the Connect cluster, <code>${connector}</code> is the name of the connector, and <code>${taskId}</code> is the ID of the task (starting from zero)</td>
- <td>A wildcard prefix of <code>${groupId}-${connector}*</code> can be used for convenience if there is no risk of conflict with other transactional IDs or if conflicts are acceptable to the user.</td>
- </tr>
- <tr>
- <td>Describe</td>
- <td>TransactionalId</td>
- <td><code>${groupId}-${connector}-${taskId}</code>, for each task that the connector will create, where <code>${groupId}</code> is the <code>group.id</code> of the Connect cluster, <code>${connector}</code> is the name of the connector, and <code>${taskId}</code> is the ID of the task (starting from zero)</td>
- <td>A wildcard prefix of <code>${groupId}-${connector}*</code> can be used for convenience if there is no risk of conflict with other transactional IDs or if conflicts are acceptable to the user.</td>
- </tr>
- <tr>
- <td>Write</td>
- <td>Topic</td>
- <td>Offsets topic used by the connector, which is either the value of the <code>offsets.storage.topic</code> property in the connector’s configuration if provided, or the value of the <code>offsets.storage.topic</code> property in the worker’s configuration if not.</td>
- <td></td>
- </tr>
- <tr>
- <td>Read</td>
- <td>Topic</td>
- <td>Offsets topic used by the connector, which is either the value of the <code>offsets.storage.topic</code> property in the connector’s configuration if provided, or the value of the <code>offsets.storage.topic</code> property in the worker’s configuration if not.</td>
- <td></td>
- </tr>
- <tr>
- <td>Describe</td>
- <td>Topic</td>
- <td>Offsets topic used by the connector, which is either the value of the <code>offsets.storage.topic</code> property in the connector’s configuration if provided, or the value of the <code>offsets.storage.topic</code> property in the worker’s configuration if not.</td>
- <td></td>
- </tr>
- <tr>
- <td>Create</td>
- <td>Topic</td>
- <td>Offsets topic used by the connector, which is either the value of the <code>offsets.storage.topic</code> property in the connector’s configuration if provided, or the value of the <code>offsets.storage.topic</code> property in the worker’s configuration if not.</td>
- <td>Only necessary if the offsets topic for the connector does not exist yet</td>
- </tr>
- <tr>
- <td>IdempotentWrite</td>
- <td>Cluster</td>
- <td>ID of the Kafka cluster that the source connector writes to</td>
- <td>The IdempotentWrite ACL has been deprecated as of 2.8 and will only be necessary for Connect clusters running on pre-2.8 Kafka clusters</td>
- </tr>
- </tbody>
- </table>
-
- <h4><a id="connect_plugindiscovery" href="#connect_plugindiscovery">Plugin Discovery</a></h4>
-
- <p>Plugin discovery is the name for the strategy which the Connect worker uses to find plugin classes and make them accessible to configure and run in connectors. This is controlled by the <a href="#connectconfigs_plugin.discovery">plugin.discovery</a> worker configuration, and has a significant impact on worker startup time. <code>service_load</code> is the fastest strategy, but care should be taken to verify that plugins are compatible before setting this configuration to <code>ser [...]
-
- <p>Prior to version 3.6, this strategy was not configurable, and behaved like the <code>only_scan</code> mode which is compatible with all plugins. For version 3.6 and later, this mode defaults to <code>hybrid_warn</code> which is also compatible with all plugins, but logs a warning for plugins which are incompatible with <code>service_load</code>. The <code>hybrid_fail</code> strategy stops the worker with an error if a plugin incompatible with <code>service_load</code> is detected, [...]
-
- <h5><a id="connect_plugindiscovery_compatibility" href="#connect_plugindiscovery_compatibility">Verifying Plugin Compatibility</a></h5>
-
- <p>To verify if all of your plugins are compatible with <code>service_load</code>, first ensure that you are using version 3.6 or later of Kafka Connect. You can then perform one of the following checks:</p>
-
- <ul>
- <li>Start your worker with the default <code>hybrid_warn</code>strategy, and WARN logs enabled for the <code>org.apache.kafka.connect</code> package. At least one WARN log message mentioning the <code>plugin.discovery</code> configuration should be printed. This log message will explicitly say that all plugins are compatible, or list the incompatible plugins.</li>
- <li>Start your worker in a test environment with <code>hybrid_fail</code>. If all plugins are compatible, startup will succeed. If at least one plugin is not compatible the worker will fail to start up, and all incompatible plugins will be listed in the exception.</li>
- </ul>
-
- <p>If the verification step succeeds, then your current set of installed plugins is compatible, and it should be safe to change the <code>plugin.discovery</code> configuration to <code>service_load</code>. If the verification fails, you cannot use <code>service_load</code> strategy and should take note of the list of incompatible plugins. All plugins must be addressed before using the <code>service_load</code> strategy. It is recommended to perform this verification after installing [...]
-
- <h5><a id="connect_plugindiscovery_migrateartifact" href="#connect_plugindiscovery_migrateartifact">Operators: Artifact Migration</a></h5>
-
- <p>As an operator of Connect, if you discover incompatible plugins, there are multiple ways to resolve the incompatibility. They are listed below from most to least preferable.</p>
-
- <ol>
- <li>Check the latest release from your plugin provider, and if it is compatible, upgrade.</li>
- <li>Contact your plugin provider and request that they migrate the plugin to be compatible, following the <a href="#connect_plugindiscovery_migratesource">source migration instructions</a>, and then upgrade to the compatible version.</li>
- <li>Migrate the plugin artifacts yourself using the included migration script.</li>
- </ol>
-
- <p>The migration script is located in <code>bin/connect-plugin-path.sh</code> and <code>bin\windows\connect-plugin-path.bat</code> of your Kafka installation. The script can migrate incompatible plugin artifacts already installed on your Connect worker's <code>plugin.path</code> by adding or modifying JAR or resource files. This is not suitable for environments using code-signing, as this can change artifacts such that they will fail signature verification. View the built-in help wit [...]
-
- <p>To perform a migration, first use the <code>list</code> subcommand to get an overview of the plugins available to the script. You must tell the script where to find plugins, which can be done with the repeatable <code>--worker-config</code>, <code>--plugin-path</code>, and <code>--plugin-location</code> arguments. The script will ignore plugins on the classpath, so any custom plugins on your classpath should be moved to the plugin path in order to be used with this migration scrip [...]
-
- <p>Once you see that all incompatible plugins are included in the listing, you can proceed to dry-run the migration with <code>sync-manifests --dry-run</code>. This will perform all parts of the migration, except for writing the results of the migration to disk. Note that the <code>sync-manifests</code> command requires all specified paths to be writable, and may alter the contents of the directories. Make a backup of your plugins in the specified paths, or copy them to a writable di [...]
-
- <p>Ensure that you have a backup of your plugins and the dry-run succeeds before removing the <code>--dry-run</code> flag and actually running the migration. If the migration fails without the <code>--dry-run</code> flag, then the partially migrated artifacts should be discarded. The migration is idempotent, so running it multiple times and on already-migrated plugins is safe. After the script finishes, you should <a href="#connect_plugindiscovery_compatibility">verify the migration [...]
-
- <h5><a id="connect_plugindiscovery_migratesource" href="#connect_plugindiscovery_migratesource">Developers: Source Migration</a></h5>
-
- <p>To make plugins compatible with <code>service_load</code>, it is necessary to add <a href="https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html">ServiceLoader</a> manifests to your source code, which should then be packaged in the release artifact. Manifests are resource files in <code>META-INF/services/</code> named after their superclass type, and contain a list of fully-qualified subclass names, one on each line.</p>
-
- <p>In order for a plugin to be compatible, it must appear as a line in a manifest corresponding to the plugin superclass it extends. If a single plugin implements multiple plugin interfaces, then it should appear in a manifest for each interface it implements. If you have no classes for a certain type of plugin, you do not need to include a manifest file for that type. If you have classes which should not be visible as plugins, they should be marked abstract. The following types are [...]
-
- <ul>
- <li><code>org.apache.kafka.connect.sink.SinkConnector</code></li>
- <li><code>org.apache.kafka.connect.source.SourceConnector</code></li>
- <li><code>org.apache.kafka.connect.storage.Converter</code></li>
- <li><code>org.apache.kafka.connect.storage.HeaderConverter</code></li>
- <li><code>org.apache.kafka.connect.transforms.Transformation</code></li>
- <li><code>org.apache.kafka.connect.transforms.predicates.Predicate</code></li>
- <li><code>org.apache.kafka.common.config.provider.ConfigProvider</code></li>
- <li><code>org.apache.kafka.connect.rest.ConnectRestExtension</code></li>
- <li><code>org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy</code></li>
- </ul>
-
- <p>For example, if you only have one connector with the fully-qualified name <code>com.example.MySinkConnector</code>, then only one manifest file must be added to resources in <code>META-INF/services/org.apache.kafka.connect.sink.SinkConnector</code>, and the contents should be similar to the following:</p>
-
- <pre><code class="language-text"># license header or comment
-com.example.MySinkConnector</code></pre>
-
- <p>You should then verify that your manifests are correct by using the <a href="#connect_plugindiscovery_compatibility">verification steps</a> with a pre-release artifact. If the verification succeeds, you can then release the plugin normally, and operators can upgrade to the compatible version.</p>
-
- <h4><a id="connect_security" href="#connect_security">Security</a></h4>
-
- <p>It's important to understand the security concerns inherent to Connect. First, Connect allows running custom plugins. These plugins can run arbitrary code, so you must trust them before installing them in your Connect clusters. By default, the REST API is unsecured and allows anyone that can access it to start and stop connectors. You should only directly expose the REST API to trusted users, otherwise it's easy to gain arbitrary code execution on Connect workers. By default, conn [...]
-
- <h3><a id="connect_development" href="#connect_development">8.3 Connector Development Guide</a></h3>
-
- <p>This guide describes how developers can write new connectors for Kafka Connect to move data between Kafka and other systems. It briefly reviews a few key concepts and then describes how to create a simple connector.</p>
-
- <h4><a id="connect_concepts" href="#connect_concepts">Core Concepts and APIs</a></h4>
-
- <h5><a id="connect_connectorsandtasks" href="#connect_connectorsandtasks">Connectors and Tasks</a></h5>
-
- <p>To copy data between Kafka and another system, users create a <code>Connector</code> for the system they want to pull data from or push data to. Connectors come in two flavors: <code>SourceConnectors</code> import data from another system (e.g. <code>JDBCSourceConnector</code> would import a relational database into Kafka) and <code>SinkConnectors</code> export data (e.g. <code>HDFSSinkConnector</code> would export the contents of a Kafka topic to an HDFS file).</p>
-
- <p><code>Connectors</code> do not perform any data copying themselves: their configuration describes the data to be copied, and the <code>Connector</code> is responsible for breaking that job into a set of <code>Tasks</code> that can be distributed to workers. These <code>Tasks</code> also come in two corresponding flavors: <code>SourceTask</code> and <code>SinkTask</code>.</p>
-
- <p>With an assignment in hand, each <code>Task</code> must copy its subset of the data to or from Kafka. In Kafka Connect, it should always be possible to frame these assignments as a set of input and output streams consisting of records with consistent schemas. Sometimes this mapping is obvious: each file in a set of log files can be considered a stream with each parsed line forming a record using the same schema and offsets stored as byte offsets in the file. In other cases it may [...]
-
-
- <h5><a id="connect_streamsandrecords" href="#connect_streamsandrecords">Streams and Records</a></h5>
-
- <p>Each stream should be a sequence of key-value records. Both the keys and values can have complex structure -- many primitive types are provided, but arrays, objects, and nested data structures can be represented as well. The runtime data format does not assume any particular serialization format; this conversion is handled internally by the framework.</p>
-
- <p>In addition to the key and value, records (both those generated by sources and those delivered to sinks) have associated stream IDs and offsets. These are used by the framework to periodically commit the offsets of data that have been processed so that in the event of failures, processing can resume from the last committed offsets, avoiding unnecessary reprocessing and duplication of events.</p>
-
- <h5><a id="connect_dynamicconnectors" href="#connect_dynamicconnectors">Dynamic Connectors</a></h5>
-
- <p>Not all jobs are static, so <code>Connector</code> implementations are also responsible for monitoring the external system for any changes that might require reconfiguration. For example, in the <code>JDBCSourceConnector</code> example, the <code>Connector</code> might assign a set of tables to each <code>Task</code>. When a new table is created, it must discover this so it can assign the new table to one of the <code>Tasks</code> by updating its configuration. When it notices a c [...]
-
-
- <h4><a id="connect_developing" href="#connect_developing">Developing a Simple Connector</a></h4>
-
- <p>Developing a connector only requires implementing two interfaces, the <code>Connector</code> and <code>Task</code>. A simple example is included with the source code for Kafka in the <code>file</code> package. This connector is meant for use in standalone mode and has implementations of a <code>SourceConnector</code>/<code>SourceTask</code> to read each line of a file and emit it as a record and a <code>SinkConnector</code>/<code>SinkTask</code> that writes each record to a file.</p>
-
- <p>The rest of this section will walk through some code to demonstrate the key steps in creating a connector, but developers should also refer to the full example source code as many details are omitted for brevity.</p>
-
- <h5><a id="connect_connectorexample" href="#connect_connectorexample">Connector Example</a></h5>
-
- <p>We'll cover the <code>SourceConnector</code> as a simple example. <code>SinkConnector</code> implementations are very similar. Pick a package and class name, these examples will use the <code>FileStreamSourceConnector</code> but substitute your own class name where appropriate. In order to <a href="#connect_plugindiscovery">make the plugin discoverable at runtime</a>, add a ServiceLoader manifest to your resources in <code>META-INF/services/org.apache.kafka.connect.source.SourceCo [...]
- <pre><code class="language-resource">com.example.FileStreamSourceConnector</code></pre>
-
- <p>Create a class that inherits from <code>SourceConnector</code> and add a field that will store the configuration information to be propagated to the task(s) (the topic to send data to, and optionally - the filename to read from and the maximum batch size):</p>
-
- <pre class="line-numbers"><code class="language-java">package com.example;
-
-public class FileStreamSourceConnector extends SourceConnector {
- private Map<String, String> props;</code></pre>
-
- <p>The easiest method to fill in is <code>taskClass()</code>, which defines the class that should be instantiated in worker processes to actually read the data:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public Class<? extends Task> taskClass() {
- return FileStreamSourceTask.class;
-}</code></pre>
-
- <p>We will define the <code>FileStreamSourceTask</code> class below. Next, we add some standard lifecycle methods, <code>start()</code> and <code>stop()</code>:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public void start(Map<String, String> props) {
- // Initialization logic and setting up of resources can take place in this method.
- // This connector doesn't need to do any of that, but we do log a helpful message to the user.
-
- this.props = props;
- AbstractConfig config = new AbstractConfig(CONFIG_DEF, props);
- String filename = config.getString(FILE_CONFIG);
- filename = (filename == null || filename.isEmpty()) ? "standard input" : config.getString(FILE_CONFIG);
- log.info("Starting file source connector reading from {}", filename);
-}
-
-@Override
-public void stop() {
- // Nothing to do since no background monitoring is required.
-}</code></pre>
-
- <p>Finally, the real core of the implementation is in <code>taskConfigs()</code>. In this case we are only
- handling a single file, so even though we may be permitted to generate more tasks as per the
- <code>maxTasks</code> argument, we return a list with only one entry:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public List<Map<String, String>> taskConfigs(int maxTasks) {
- // Note that the task configs could contain configs additional to or different from the connector configs if needed. For instance,
- // if different tasks have different responsibilities, or if different tasks are meant to process different subsets of the source data stream).
- ArrayList<Map<String, String>> configs = new ArrayList<>();
- // Only one input stream makes sense.
- configs.add(props);
- return configs;
-}</code></pre>
-
- <p>Even with multiple tasks, this method implementation is usually pretty simple. It just has to determine the number of input tasks, which may require contacting the remote service it is pulling data from, and then divvy them up. Because some patterns for splitting work among tasks are so common, some utilities are provided in <code>ConnectorUtils</code> to simplify these cases.</p>
-
- <p>Note that this simple example does not include dynamic input. See the discussion in the next section for how to trigger updates to task configs.</p>
-
- <h5><a id="connect_taskexample" href="#connect_taskexample">Task Example - Source Task</a></h5>
-
- <p>Next we'll describe the implementation of the corresponding <code>SourceTask</code>. The implementation is short, but too long to cover completely in this guide. We'll use pseudo-code to describe most of the implementation, but you can refer to the source code for the full example.</p>
-
- <p>Just as with the connector, we need to create a class inheriting from the appropriate base <code>Task</code> class. It also has some standard lifecycle methods:</p>
-
-
- <pre class="line-numbers"><code class="language-java">public class FileStreamSourceTask extends SourceTask {
- private String filename;
- private InputStream stream;
- private String topic;
- private int batchSize;
-
- @Override
- public void start(Map<String, String> props) {
- filename = props.get(FileStreamSourceConnector.FILE_CONFIG);
- stream = openOrThrowError(filename);
- topic = props.get(FileStreamSourceConnector.TOPIC_CONFIG);
- batchSize = props.get(FileStreamSourceConnector.TASK_BATCH_SIZE_CONFIG);
- }
-
- @Override
- public synchronized void stop() {
- stream.close();
- }
-}</code></pre>
-
- <p>These are slightly simplified versions, but show that these methods should be relatively simple and the only work they should perform is allocating or freeing resources. There are two points to note about this implementation. First, the <code>start()</code> method does not yet handle resuming from a previous offset, which will be addressed in a later section. Second, the <code>stop()</code> method is synchronized. This will be necessary because <code>SourceTasks</code> are given a [...]
-
- <p>Next, we implement the main functionality of the task, the <code>poll()</code> method which gets events from the input system and returns a <code>List<SourceRecord></code>:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public List<SourceRecord> poll() throws InterruptedException {
- try {
- ArrayList<SourceRecord> records = new ArrayList<>();
- while (streamValid(stream) && records.isEmpty()) {
- LineAndOffset line = readToNextLine(stream);
- if (line != null) {
- Map<String, Object> sourcePartition = Collections.singletonMap("filename", filename);
- Map<String, Object> sourceOffset = Collections.singletonMap("position", streamOffset);
- records.add(new SourceRecord(sourcePartition, sourceOffset, topic, Schema.STRING_SCHEMA, line));
- if (records.size() >= batchSize) {
- return records;
- }
- } else {
- Thread.sleep(1);
- }
- }
- return records;
- } catch (IOException e) {
- // Underlying stream was killed, probably as a result of calling stop. Allow to return
- // null, and driving thread will handle any shutdown if necessary.
- }
- return null;
-}</code></pre>
-
- <p>Again, we've omitted some details, but we can see the important steps: the <code>poll()</code> method is going to be called repeatedly, and for each call it will loop trying to read records from the file. For each line it reads, it also tracks the file offset. It uses this information to create an output <code>SourceRecord</code> with four pieces of information: the source partition (there is only one, the single file being read), source offset (byte offset in the file), output to [...]
-
- <p>Note that this implementation uses the normal Java <code>InputStream</code> interface and may sleep if data is not available. This is acceptable because Kafka Connect provides each task with a dedicated thread. While task implementations have to conform to the basic <code>poll()</code> interface, they have a lot of flexibility in how they are implemented. In this case, an NIO-based implementation would be more efficient, but this simple approach works, is quick to implement, and i [...]
-
- <p>Although not used in the example, <code>SourceTask</code> also provides two APIs to commit offsets in the source system: <code>commit</code> and <code>commitRecord</code>. The APIs are provided for source systems which have an acknowledgement mechanism for messages. Overriding these methods allows the source connector to acknowledge messages in the source system, either in bulk or individually, once they have been written to Kafka.
- The <code>commit</code> API stores the offsets in the source system, up to the offsets that have been returned by <code>poll</code>. The implementation of this API should block until the commit is complete. The <code>commitRecord</code> API saves the offset in the source system for each <code>SourceRecord</code> after it is written to Kafka. As Kafka Connect will record offsets automatically, <code>SourceTask</code>s are not required to implement them. In cases where a connector [...]
-
- <h5><a id="connect_sinktasks" href="#connect_sinktasks">Sink Tasks</a></h5>
-
- <p>The previous section described how to implement a simple <code>SourceTask</code>. Unlike <code>SourceConnector</code> and <code>SinkConnector</code>, <code>SourceTask</code> and <code>SinkTask</code> have very different interfaces because <code>SourceTask</code> uses a pull interface and <code>SinkTask</code> uses a push interface. Both share the common lifecycle methods, but the <code>SinkTask</code> interface is quite different:</p>
-
- <pre class="line-numbers"><code class="language-java">public abstract class SinkTask implements Task {
- public void initialize(SinkTaskContext context) {
- this.context = context;
- }
-
- public abstract void put(Collection<SinkRecord> records);
-
- public void flush(Map<TopicPartition, OffsetAndMetadata> currentOffsets) {
- }
-}</code></pre>
-
- <p>The <code>SinkTask</code> documentation contains full details, but this interface is nearly as simple as the <code>SourceTask</code>. The <code>put()</code> method should contain most of the implementation, accepting sets of <code>SinkRecords</code>, performing any required translation, and storing them in the destination system. This method does not need to ensure the data has been fully written to the destination system before returning. In fact, in many cases internal buffering [...]
-
- <p>The <code>flush()</code> method is used during the offset commit process, which allows tasks to recover from failures and resume from a safe point such that no events will be missed. The method should push any outstanding data to the destination system and then block until the write has been acknowledged. The <code>offsets</code> parameter can often be ignored, but is useful in some cases where implementations want to store offset information in the destination store to provide ex [...]
- delivery. For example, an HDFS connector could do this and use atomic move operations to make sure the <code>flush()</code> operation atomically commits the data and offsets to a final location in HDFS.</p>
-
- <h5><a id="connect_errantrecordreporter" href="#connect_errantrecordreporter">Errant Record Reporter</a></h5>
-
- <p>When <a href="#connect_errorreporting">error reporting</a> is enabled for a connector, the connector can use an <code>ErrantRecordReporter</code> to report problems with individual records sent to a sink connector. The following example shows how a connector's <code>SinkTask</code> subclass might obtain and use the <code>ErrantRecordReporter</code>, safely handling a null reporter when the DLQ is not enabled or when the connector is installed in an older Connect runtime that doesn [...]
-
- <pre class="line-numbers"><code class="language-java">private ErrantRecordReporter reporter;
-
-@Override
-public void start(Map<String, String> props) {
- ...
- try {
- reporter = context.errantRecordReporter(); // may be null if DLQ not enabled
- } catch (NoSuchMethodException | NoClassDefFoundError e) {
- // Will occur in Connect runtimes earlier than 2.6
- reporter = null;
- }
-}
-
-@Override
-public void put(Collection<SinkRecord> records) {
- for (SinkRecord record: records) {
- try {
- // attempt to process and send record to data sink
- process(record);
- } catch(Exception e) {
- if (reporter != null) {
- // Send errant record to error reporter
- reporter.report(record, e);
- } else {
- // There's no error reporter, so fail
- throw new ConnectException("Failed on record", e);
- }
- }
- }
-}</code></pre>
-
- <h5><a id="connect_resuming" href="#connect_resuming">Resuming from Previous Offsets</a></h5>
-
- <p>The <code>SourceTask</code> implementation included a stream ID (the input filename) and offset (position in the file) with each record. The framework uses this to commit offsets periodically so that in the case of a failure, the task can recover and minimize the number of events that are reprocessed and possibly duplicated (or to resume from the most recent offset if Kafka Connect was stopped gracefully, e.g. in standalone mode or due to a job reconfiguration). This commit proces [...]
-
- <p>To correctly resume upon startup, the task can use the <code>SourceContext</code> passed into its <code>initialize()</code> method to access the offset data. In <code>initialize()</code>, we would add a bit more code to read the offset (if it exists) and seek to that position:</p>
-
- <pre class="line-numbers"><code class="language-java">stream = new FileInputStream(filename);
-Map<String, Object> offset = context.offsetStorageReader().offset(Collections.singletonMap(FILENAME_FIELD, filename));
-if (offset != null) {
- Long lastRecordedOffset = (Long) offset.get("position");
- if (lastRecordedOffset != null)
- seekToOffset(stream, lastRecordedOffset);
-}</code></pre>
-
- <p>Of course, you might need to read many keys for each of the input streams. The <code>OffsetStorageReader</code> interface also allows you to issue bulk reads to efficiently load all offsets, then apply them by seeking each input stream to the appropriate position.</p>
-
- <h5><a id="connect_exactlyoncesourceconnectors" href="#connect_exactlyoncesourceconnectors">Exactly-once source connectors</a></h5>
-
- <h6>Supporting exactly-once</h6>
-
- <p>With the passing of <a href="https://cwiki.apache.org/confluence/x/Vg0rCQ">KIP-618</a>, Kafka Connect supports exactly-once source connectors as of version 3.3.0. In order for a source connector to take advantage of this support, it must be able to provide meaningful source offsets for each record that it emits, and resume consumption from the external system at the exact position corresponding to any of those offsets without dropping or duplicating messages.</p>
-
- <h6>Defining transaction boundaries</h6>
-
- <p>By default, the Kafka Connect framework will create and commit a new Kafka transaction for each batch of records that a source task returns from its <code>poll</code> method. However, connectors can also define their own transaction boundaries, which can be enabled by users by setting the <code>transaction.boundary</code> property to <code>connector</code> in the config for the connector.</p>
-
- <p>If enabled, the connector's tasks will have access to a <code>TransactionContext</code> from their <code>SourceTaskContext</code>, which they can use to control when transactions are aborted and committed.</p>
-
- <p>For example, to commit a transaction at least every ten records:</p>
-
- <pre class="line-numbers"><code class="language-java">private int recordsSent;
-
-@Override
-public void start(Map<String, String> props) {
- this.recordsSent = 0;
-}
-
-@Override
-public List<SourceRecord> poll() {
- List<SourceRecord> records = fetchRecords();
- boolean shouldCommit = false;
- for (SourceRecord record : records) {
- if (++this.recordsSent >= 10) {
- shouldCommit = true;
- }
- }
- if (shouldCommit) {
- this.recordsSent = 0;
- this.context.transactionContext().commitTransaction();
- }
- return records;
-}</code></pre>
-
- <p>Or to commit a transaction for exactly every tenth record:</p>
-
- <pre class="line-numbers"><code class="language-java">private int recordsSent;
-
-@Override
-public void start(Map<String, String> props) {
- this.recordsSent = 0;
-}
-
-@Override
-public List<SourceRecord> poll() {
- List<SourceRecord> records = fetchRecords();
- for (SourceRecord record : records) {
- if (++this.recordsSent % 10 == 0) {
- this.context.transactionContext().commitTransaction(record);
- }
- }
- return records;
-}</code></pre>
-
- <p>Most connectors do not need to define their own transaction boundaries. However, it may be useful if files or objects in the source system are broken up into multiple source records, but should be delivered atomically. Additionally, it may be useful if it is impossible to give each source record a unique source offset, if every record with a given offset is delivered within a single transaction.</p>
-
- <p>Note that if the user has not enabled connector-defined transaction boundaries in the connector configuration, the <code>TransactionContext</code> returned by <code>context.transactionContext()</code> will be <code>null</code>.</p>
-
- <h6>Validation APIs</h6>
-
- <p>A few additional preflight validation APIs can be implemented by source connector developers.</p>
-
- <p>Some users may require exactly-once semantics from a connector. In this case, they may set the <code>exactly.once.support</code> property to <code>required</code> in the configuration for the connector. When this happens, the Kafka Connect framework will ask the connector whether it can provide exactly-once semantics with the specified configuration. This is done by invoking the <code>exactlyOnceSupport</code> method on the connector.</p>
-
- <p>If a connector doesn't support exactly-once semantics, it should still implement this method to let users know for certain that it cannot provide exactly-once semantics:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public ExactlyOnceSupport exactlyOnceSupport(Map<String, String> props) {
- // This connector cannot provide exactly-once semantics under any conditions
- return ExactlyOnceSupport.UNSUPPORTED;
-}
-</code></pre>
-
- <p>Otherwise, a connector should examine the configuration, and return <code>ExactlyOnceSupport.SUPPORTED</code> if it can provide exactly-once semantics:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public ExactlyOnceSupport exactlyOnceSupport(Map<String, String> props) {
- // This connector can always provide exactly-once semantics
- return ExactlyOnceSupport.SUPPORTED;
-}</code></pre>
-
- <p>Additionally, if the user has configured the connector to define its own transaction boundaries, the Kafka Connect framework will ask the connector whether it can define its own transaction boundaries with the specified configuration, using the <code>canDefineTransactionBoundaries</code> method:</p>
-
- <pre class="line-numbers"><code class="language-java">@Override
-public ConnectorTransactionBoundaries canDefineTransactionBoundaries(Map<String, String> props) {
- // This connector can always define its own transaction boundaries
- return ConnectorTransactionBoundaries.SUPPORTED;
-}</code></pre>
-
- <p>This method should only be implemented for connectors that can define their own transaction boundaries in some cases. If a connector is never able to define its own transaction boundaries, it does not need to implement this method.</p>
-
- <h4><a id="connect_dynamicio" href="#connect_dynamicio">Dynamic Input/Output Streams</a></h4>
-
- <p>Kafka Connect is intended to define bulk data copying jobs, such as copying an entire database rather than creating many jobs to copy each table individually. One consequence of this design is that the set of input or output streams for a connector can vary over time.</p>
-
- <p>Source connectors need to monitor the source system for changes, e.g. table additions/deletions in a database. When they pick up changes, they should notify the framework via the <code>ConnectorContext</code> object that reconfiguration is necessary. For example, in a <code>SourceConnector</code>:</p>
-
- <pre class="line-numbers"><code class="language-java">if (inputsChanged())
- this.context.requestTaskReconfiguration();</code></pre>
-
- <p>The framework will promptly request new configuration information and update the tasks, allowing them to gracefully commit their progress before reconfiguring them. Note that in the <code>SourceConnector</code> this monitoring is currently left up to the connector implementation. If an extra thread is required to perform this monitoring, the connector must allocate it itself.</p>
-
- <p>Ideally this code for monitoring changes would be isolated to the <code>Connector</code> and tasks would not need to worry about them. However, changes can also affect tasks, most commonly when one of their input streams is destroyed in the input system, e.g. if a table is dropped from a database. If the <code>Task</code> encounters the issue before the <code>Connector</code>, which will be common if the <code>Connector</code> needs to poll for changes, the <code>Task</code> will [...]
-
- <p><code>SinkConnectors</code> usually only have to handle the addition of streams, which may translate to new entries in their outputs (e.g., a new database table). The framework manages any changes to the Kafka input, such as when the set of input topics changes because of a regex subscription. <code>SinkTasks</code> should expect new input streams, which may require creating new resources in the downstream system, such as a new table in a database. The trickiest situation to handl [...]
-
- <h4><a id="connect_configs" href="#connect_configs">Configuration Validation</a></h4>
-
- <p>Kafka Connect allows you to validate connector configurations before submitting a connector to be executed and can provide feedback about errors and recommended values. To take advantage of this, connector developers need to provide an implementation of <code>config()</code> to expose the configuration definition to the framework.</p>
-
- <p>The following code in <code>FileStreamSourceConnector</code> defines the configuration and exposes it to the framework.</p>
-
- <pre class="line-numbers"><code class="language-java">static final ConfigDef CONFIG_DEF = new ConfigDef()
- .define(FILE_CONFIG, Type.STRING, null, Importance.HIGH, "Source filename. If not specified, the standard input will be used")
- .define(TOPIC_CONFIG, Type.STRING, ConfigDef.NO_DEFAULT_VALUE, new ConfigDef.NonEmptyString(), Importance.HIGH, "The topic to publish data to")
- .define(TASK_BATCH_SIZE_CONFIG, Type.INT, DEFAULT_TASK_BATCH_SIZE, Importance.LOW,
- "The maximum number of records the source task can read from the file each time it is polled");
-
-public ConfigDef config() {
- return CONFIG_DEF;
-}</code></pre>
-
- <p><code>ConfigDef</code> class is used for specifying the set of expected configurations. For each configuration, you can specify the name, the type, the default value, the documentation, the group information, the order in the group, the width of the configuration value and the name suitable for display in the UI. Plus, you can provide special validation logic used for single configuration validation by overriding the <code>Validator</code> class. Moreover, as there may be dependen [...]
-
- <p>Also, the <code>validate()</code> method in <code>Connector</code> provides a default validation implementation which returns a list of allowed configurations together with configuration errors and recommended values for each configuration. However, it does not use the recommended values for configuration validation. You may provide an override of the default implementation for customized configuration validation, which may use the recommended values.</p>
-
- <h4><a id="connect_schemas" href="#connect_schemas">Working with Schemas</a></h4>
-
- <p>The FileStream connectors are good examples because they are simple, but they also have trivially structured data -- each line is just a string. Almost all practical connectors will need schemas with more complex data formats.</p>
-
- <p>To create more complex data, you'll need to work with the Kafka Connect <code>data</code> API. Most structured records will need to interact with two classes in addition to primitive types: <code>Schema</code> and <code>Struct</code>.</p>
-
- <p>The API documentation provides a complete reference, but here is a simple example creating a <code>Schema</code> and <code>Struct</code>:</p>
-
- <pre class="line-numbers"><code class="language-java">Schema schema = SchemaBuilder.struct().name(NAME)
- .field("name", Schema.STRING_SCHEMA)
- .field("age", Schema.INT_SCHEMA)
- .field("admin", SchemaBuilder.bool().defaultValue(false).build())
- .build();
-
-Struct struct = new Struct(schema)
- .put("name", "Barbara Liskov")
- .put("age", 75);</code></pre>
-
- <p>If you are implementing a source connector, you'll need to decide when and how to create schemas. Where possible, you should avoid recomputing them as much as possible. For example, if your connector is guaranteed to have a fixed schema, create it statically and reuse a single instance.</p>
-
- <p>However, many connectors will have dynamic schemas. One simple example of this is a database connector. Considering even just a single table, the schema will not be predefined for the entire connector (as it varies from table to table). But it also may not be fixed for a single table over the lifetime of the connector since the user may execute an <code>ALTER TABLE</code> command. The connector must be able to detect these changes and react appropriately.</p>
-
- <p>Sink connectors are usually simpler because they are consuming data and therefore do not need to create schemas. However, they should take just as much care to validate that the schemas they receive have the expected format. When the schema does not match -- usually indicating the upstream producer is generating invalid data that cannot be correctly translated to the destination system -- sink connectors should throw an exception to indicate this error to the system.</p>
-
- <h3><a id="connect_administration" href="#connect_administration">8.4 Administration</a></h3>
-
- <p>
- Kafka Connect's <a href="#connect_rest">REST layer</a> provides a set of APIs to enable administration of the cluster. This includes APIs to view the configuration of connectors and the status of their tasks, as well as to alter their current behavior (e.g. changing configuration and restarting tasks).
- </p>
-
- <p>
- When a connector is first submitted to the cluster, a rebalance is triggered between the Connect workers in order to distribute the load that consists of the tasks of the new connector.
- This same rebalancing procedure is also used when connectors increase or decrease the number of tasks they require, when a connector's configuration is changed, or when a
- worker is added or removed from the group as part of an intentional upgrade of the Connect cluster or due to a failure.
- </p>
-
- <p>
- In versions prior to 2.3.0, the Connect workers would rebalance the full set of connectors and their tasks in the cluster as a simple way to make sure that each worker has approximately the same amount of work.
- This behavior can be still enabled by setting <code>connect.protocol=eager</code>.
- </p>
-
- <p>
- Starting with 2.3.0, Kafka Connect is using by default a protocol that performs
- <a href="https://cwiki.apache.org/confluence/x/Y4MCBg">incremental cooperative rebalancing</a>
- that incrementally balances the connectors and tasks across the Connect workers, affecting only tasks that are new, to be removed, or need to move from one worker to another.
- Other tasks are not stopped and restarted during the rebalance, as they would have been with the old protocol.
- </p>
-
- <p>
- If a Connect worker leaves the group, intentionally or due to a failure, Connect waits for <code>scheduled.rebalance.max.delay.ms</code> before triggering a rebalance.
- This delay defaults to five minutes (<code>300000ms</code>) to tolerate failures or upgrades of workers without immediately redistributing the load of a departing worker.
- If this worker returns within the configured delay, it gets its previously assigned tasks in full.
- However, this means that the tasks will remain unassigned until the time specified by <code>scheduled.rebalance.max.delay.ms</code> elapses.
- If a worker does not return within that time limit, Connect will reassign those tasks among the remaining workers in the Connect cluster.
- </p>
-
- <p>
- The new Connect protocol is enabled when all the workers that form the Connect cluster are configured with <code>connect.protocol=compatible</code>, which is also the default value when this property is missing.
- Therefore, upgrading to the new Connect protocol happens automatically when all the workers upgrade to 2.3.0.
- A rolling upgrade of the Connect cluster will activate incremental cooperative rebalancing when the last worker joins on version 2.3.0.
- </p>
-
- <p>
- You can use the REST API to view the current status of a connector and its tasks, including the ID of the worker to which each was assigned. For example, the <code>GET /connectors/file-source/status</code> request shows the status of a connector named <code>file-source</code>:
- </p>
-
- <pre class="line-numbers"><code class="language-json">{
- "name": "file-source",
- "connector": {
- "state": "RUNNING",
- "worker_id": "192.168.1.208:8083"
- },
- "tasks": [
- {
- "id": 0,
- "state": "RUNNING",
- "worker_id": "192.168.1.209:8083"
- }
- ]
-}</code></pre>
-
- <p>
- Connectors and their tasks publish status updates to a shared topic (configured with <code>status.storage.topic</code>) which all workers in the cluster monitor. Because the workers consume this topic asynchronously, there is typically a (short) delay before a state change is visible through the status API. The following states are possible for a connector or one of its tasks:
- </p>
-
- <ul>
- <li><b>UNASSIGNED:</b> The connector/task has not yet been assigned to a worker.</li>
- <li><b>RUNNING:</b> The connector/task is running.</li>
- <li><b>PAUSED:</b> The connector/task has been administratively paused.</li>
- <li><b>STOPPED:</b> The connector has been stopped. Note that this state is not applicable to tasks because the tasks for a stopped connector are shut down and won't be visible in the status API.</li>
- <li><b>FAILED:</b> The connector/task has failed (usually by raising an exception, which is reported in the status output).</li>
- <li><b>RESTARTING:</b> The connector/task is either actively restarting or is expected to restart soon</li>
- </ul>
-
- <p>
- In most cases, connector and task states will match, though they may be different for short periods of time when changes are occurring or if tasks have failed. For example, when a connector is first started, there may be a noticeable delay before the connector and its tasks have all transitioned to the RUNNING state. States will also diverge when tasks fail since Connect does not automatically restart failed tasks. To restart a connector/task manually, you can use the restart APIs li [...]
- </p>
-
- <p>
- Starting with 2.5.0, Kafka Connect uses the <code>status.storage.topic</code> to also store information related to the topics that each connector is using. Connect Workers use these per-connector topic status updates to respond to requests to the REST endpoint <code>GET /connectors/{name}/topics</code> by returning the set of topic names that a connector is using. A request to the REST endpoint <code>PUT /connectors/{name}/topics/reset</code> resets the set of active topics for a con [...]
- </p>
-
- <p>
- It's sometimes useful to temporarily stop the message processing of a connector. For example, if the remote system is undergoing maintenance, it would be preferable for source connectors to stop polling it for new data instead of filling logs with exception spam. For this use case, Connect offers a pause/resume API. While a source connector is paused, Connect will stop polling it for additional records. While a sink connector is paused, Connect will stop pushing new messages to it. T [...]
- </p>
-
- <p>
- In 3.5.0, Connect introduced a stop API that completely shuts down the tasks for a connector and deallocates any resources claimed by them. This is different from pausing a connector where tasks are left idling and any resources claimed by them are left allocated (which allows the connector to begin processing data quickly once it is resumed). Stopping a connector is more efficient from a resource usage standpoint than pausing it, but can cause it to take longer to begin processing d [...]
- </p>
-</script>
-
-<div class="p-connect"></div>
diff --git a/docs/design.html b/docs/design.html
deleted file mode 100644
index 32b429c3dd5..00000000000
--- a/docs/design.html
+++ /dev/null
@@ -1,766 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script id="design-template" type="text/x-handlebars-template">
- <h3 class="anchor-heading"><a id="majordesignelements" class="anchor-link"></a><a href="#majordesignelements">4.1 Motivation</a></h3>
- <p>
- We designed Kafka to be able to act as a unified platform for handling all the real-time data feeds <a href="#introduction">a large company might have</a>. To do this we had to think through a fairly broad set of use cases.
- <p>
- It would have to have high-throughput to support high volume event streams such as real-time log aggregation.
- <p>
- It would need to deal gracefully with large data backlogs to be able to support periodic data loads from offline systems.
- <p>
- It also meant the system would have to handle low-latency delivery to handle more traditional messaging use-cases.
- <p>
- We wanted to support partitioned, distributed, real-time processing of these feeds to create new, derived feeds. This motivated our partitioning and consumer model.
- <p>
- Finally in cases where the stream is fed into other data systems for serving, we knew the system would have to be able to guarantee fault-tolerance in the presence of machine failures.
- <p>
- Supporting these uses led us to a design with a number of unique elements, more akin to a database log than a traditional messaging system. We will outline some elements of the design in the following sections.
-
- <h3 class="anchor-heading"><a id="persistence" class="anchor-link"></a><a href="#persistence">4.2 Persistence</a></h3>
- <h4><a id="design_filesystem" href="#design_filesystem">Don't fear the filesystem!</a></h4>
- <p>
- Kafka relies heavily on the filesystem for storing and caching messages. There is a general perception that "disks are slow" which makes people skeptical that a persistent structure can offer competitive performance.
- In fact disks are both much slower and much faster than people expect depending on how they are used; and a properly designed disk structure can often be as fast as the network.
- <p>
- The key fact about disk performance is that the throughput of hard drives has been diverging from the latency of a disk seek for the last decade. As a result the performance of linear writes on a <a href="https://en.wikipedia.org/wiki/Non-RAID_drive_architectures">JBOD</a>
- configuration with six 7200rpm SATA RAID-5 array is about 600MB/sec but the performance of random writes is only about 100kB/sec—a difference of over 6000X. These linear reads and writes are the most
- predictable of all usage patterns, and are heavily optimized by the operating system. A modern operating system provides read-ahead and write-behind techniques that prefetch data in large block multiples and
- group smaller logical writes into large physical writes. A further discussion of this issue can be found in this <a href="https://queue.acm.org/detail.cfm?id=1563874">ACM Queue article</a>; they actually find that
- <a href="https://deliveryimages.acm.org/10.1145/1570000/1563874/jacobs3.jpg">sequential disk access can in some cases be faster than random memory access!</a>
- <p>
- To compensate for this performance divergence, modern operating systems have become increasingly aggressive in their use of main memory for disk caching. A modern OS will happily divert <i>all</i> free memory to
- disk caching with little performance penalty when the memory is reclaimed. All disk reads and writes will go through this unified cache. This feature cannot easily be turned off without using direct I/O, so even
- if a process maintains an in-process cache of the data, this data will likely be duplicated in OS pagecache, effectively storing everything twice.
- <p>
- Furthermore, we are building on top of the JVM, and anyone who has spent any time with Java memory usage knows two things:
- <ol>
- <li>The memory overhead of objects is very high, often doubling the size of the data stored (or worse).</li>
- <li>Java garbage collection becomes increasingly fiddly and slow as the in-heap data increases.</li>
- </ol>
- <p>
- As a result of these factors using the filesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure—we at least double the available cache by having automatic access
- to all free memory, and likely double again by storing a compact byte structure rather than individual objects. Doing so will result in a cache of up to 28-30GB on a 32GB machine without GC penalties.
- Furthermore, this cache will stay warm even if the service is restarted, whereas the in-process cache will need to be rebuilt in memory (which for a 10GB cache may take 10 minutes) or else it will need to start
- with a completely cold cache (which likely means terrible initial performance). This also greatly simplifies the code as all logic for maintaining coherency between the cache and filesystem is now in the OS,
- which tends to do so more efficiently and more correctly than one-off in-process attempts. If your disk usage favors linear reads then read-ahead is effectively pre-populating this cache with useful data on each
- disk read.
- <p>
- This suggests a design which is very simple: rather than maintain as much as possible in-memory and flush it all out to the filesystem in a panic when we run out of space, we invert that. All data is immediately
- written to a persistent log on the filesystem without necessarily flushing to disk. In effect this just means that it is transferred into the kernel's pagecache.
- <p>
- This style of pagecache-centric design is described in an <a href="https://varnish-cache.org/wiki/ArchitectNotes">article</a> on the design of Varnish here (along with a healthy dose of arrogance).
-
- <h4 class="anchor-heading"><a id="design_constanttime" class="anchor-link"></a><a href="#design_constanttime">Constant Time Suffices</a></h4>
- <p>
- The persistent data structure used in messaging systems are often a per-consumer queue with an associated BTree or other general-purpose random access data structures to maintain metadata about messages.
- BTrees are the most versatile data structure available, and make it possible to support a wide variety of transactional and non-transactional semantics in the messaging system.
- They do come with a fairly high cost, though: Btree operations are O(log N). Normally O(log N) is considered essentially equivalent to constant time, but this is not true for disk operations.
- Disk seeks come at 10 ms a pop, and each disk can do only one seek at a time so parallelism is limited. Hence even a handful of disk seeks leads to very high overhead.
- Since storage systems mix very fast cached operations with very slow physical disk operations, the observed performance of tree structures is often superlinear as data increases with fixed cache--i.e. doubling
- your data makes things much worse than twice as slow.
- <p>
- Intuitively a persistent queue could be built on simple reads and appends to files as is commonly the case with logging solutions. This structure has the advantage that all operations are O(1) and reads do not
- block writes or each other. This has obvious performance advantages since the performance is completely decoupled from the data size—one server can now take full advantage of a number of cheap,
- low-rotational speed 1+TB SATA drives. Though they have poor seek performance, these drives have acceptable performance for large reads and writes and come at 1/3 the price and 3x the capacity.
- <p>
- Having access to virtually unlimited disk space without any performance penalty means that we can provide some features not usually found in a messaging system. For example, in Kafka, instead of attempting to
- delete messages as soon as they are consumed, we can retain messages for a relatively long period (say a week). This leads to a great deal of flexibility for consumers, as we will describe.
-
- <h3 class="anchor-heading"><a id="maximizingefficiency" class="anchor-link"></a><a href="#maximizingefficiency">4.3 Efficiency</a></h3>
- <p>
- We have put significant effort into efficiency. One of our primary use cases is handling web activity data, which is very high volume: each page view may generate dozens of writes. Furthermore, we assume each
- message published is read by at least one consumer (often many), hence we strive to make consumption as cheap as possible.
- <p>
- We have also found, from experience building and running a number of similar systems, that efficiency is a key to effective multi-tenant operations. If the downstream infrastructure service can easily become a
- bottleneck due to a small bump in usage by the application, such small changes will often create problems. By being very fast we help ensure that the application will tip over under load before the infrastructure.
- This is particularly important when trying to run a centralized service that supports dozens or hundreds of applications on a centralized cluster as changes in usage patterns are a near-daily occurrence.
- <p>
- We discussed disk efficiency in the previous section. Once poor disk access patterns have been eliminated, there are two common causes of inefficiency in this type of system: too many small I/O operations, and
- excessive byte copying.
- <p>
- The small I/O problem happens both between the client and the server and in the server's own persistent operations.
- <p>
- To avoid this, our protocol is built around a "message set" abstraction that naturally groups messages together. This allows network requests to group messages together and amortize the overhead of the network
- roundtrip rather than sending a single message at a time. The server in turn appends chunks of messages to its log in one go, and the consumer fetches large linear chunks at a time.
- <p>
- This simple optimization produces orders of magnitude speed up. Batching leads to larger network packets, larger sequential disk operations, contiguous memory blocks, and so on, all of which allows Kafka to turn
- a bursty stream of random message writes into linear writes that flow to the consumers.
- <p>
- The other inefficiency is in byte copying. At low message rates this is not an issue, but under load the impact is significant. To avoid this we employ a standardized binary message format that is shared by the
- producer, the broker, and the consumer (so data chunks can be transferred without modification between them).
- <p>
- The message log maintained by the broker is itself just a directory of files, each populated by a sequence of message sets that have been written to disk in the same format used by the producer and consumer.
- Maintaining this common format allows optimization of the most important operation: network transfer of persistent log chunks. Modern Unix operating systems offer a highly optimized code path for transferring data
- out of pagecache to a socket; in Linux this is done with the <a href="https://man7.org/linux/man-pages/man2/sendfile.2.html">sendfile system call</a>.
- <p>
- To understand the impact of sendfile, it is important to understand the common data path for transfer of data from file to socket:
- <ol>
- <li>The operating system reads data from the disk into pagecache in kernel space</li>
- <li>The application reads the data from kernel space into a user-space buffer</li>
- <li>The application writes the data back into kernel space into a socket buffer</li>
- <li>The operating system copies the data from the socket buffer to the NIC buffer where it is sent over the network</li>
- </ol>
- <p>
- This is clearly inefficient, there are four copies and two system calls. Using sendfile, this re-copying is avoided by allowing the OS to send the data from pagecache to the network directly. So in this optimized
- path, only the final copy to the NIC buffer is needed.
- <p>
- We expect a common use case to be multiple consumers on a topic. Using the zero-copy optimization above, data is copied into pagecache exactly once and reused on each consumption instead of being stored in memory
- and copied out to user-space every time it is read. This allows messages to be consumed at a rate that approaches the limit of the network connection.
- <p>
- This combination of pagecache and sendfile means that on a Kafka cluster where the consumers are mostly caught up you will see no read activity on the disks whatsoever as they will be serving data entirely from cache.
- <p>
- TLS/SSL libraries operate at the user space (in-kernel <code>SSL_sendfile</code> is currently not supported by Kafka). Due to this restriction, <code>sendfile</code> is not used when SSL is enabled. For enabling
- SSL configuration, refer to <code>security.protocol</code> and <code>security.inter.broker.protocol</code>
- <p>
- For more background on the sendfile and zero-copy support in Java, see this <a href="https://developer.ibm.com/articles/j-zerocopy/">article</a>.
-
- <h4 class="anchor-heading"><a id="design_compression" class="anchor-link"></a><a href="#design_compression">End-to-end Batch Compression</a></h4>
- <p>
- In some cases the bottleneck is actually not CPU or disk but network bandwidth. This is particularly true for a data pipeline that needs to send messages between data centers over a wide-area network. Of course,
- the user can always compress its messages one at a time without any support needed from Kafka, but this can lead to very poor compression ratios as much of the redundancy is due to repetition between messages of
- the same type (e.g. field names in JSON or user agents in web logs or common string values). Efficient compression requires compressing multiple messages together rather than compressing each message individually.
- <p>
- Kafka supports this with an efficient batching format. A batch of messages can be grouped together, compressed, and sent to the server in this form. The broker decompresses the batch in order to validate it. For
- example, it validates that the number of records in the batch is same as what batch header states. This batch of messages is then written to disk in compressed form. The batch will remain compressed in the log and
- it will also be transmitted to the consumer in compressed form. The consumer decompresses any compressed data that it receives.
- <p>
- Kafka supports GZIP, Snappy, LZ4 and ZStandard compression protocols. More details on compression can be found <a href="https://cwiki.apache.org/confluence/x/S5qoAQ">here</a>.
-
- <h3 class="anchor-heading"><a id="theproducer" class="anchor-link"></a><a href="#theproducer">4.4 The Producer</a></h3>
-
- <h4 class="anchor-heading"><a id="design_loadbalancing" class="anchor-link"></a><a href="#design_loadbalancing">Load balancing</a></h4>
- <p>
- The producer sends data directly to the broker that is the leader for the partition without any intervening routing tier. To help the producer do this all Kafka nodes can answer a request for metadata about which
- servers are alive and where the leaders for the partitions of a topic are at any given time to allow the producer to appropriately direct its requests.
- <p>
- The client controls which partition it publishes messages to. This can be done at random, implementing a kind of random load balancing, or it can be done by some semantic partitioning function. We expose the interface
- for semantic partitioning by allowing the user to specify a key to partition by and using this to hash to a partition (there is also an option to override the partition function if need be). For example if the key
- chosen was a user id then all data for a given user would be sent to the same partition. This in turn will allow consumers to make locality assumptions about their consumption. This style of partitioning is explicitly
- designed to allow locality-sensitive processing in consumers.
-
- <h4 class="anchor-heading"><a id="design_asyncsend" class="anchor-link"></a><a href="#design_asyncsend">Asynchronous send</a></h4>
- <p>
- Batching is one of the big drivers of efficiency, and to enable batching the Kafka producer will attempt to accumulate data in memory and to send out larger batches in a single request. The batching can be configured
- to accumulate no more than a fixed number of messages and to wait no longer than some fixed latency bound (say 64kB or 10 ms). This allows the accumulation of more bytes to send, and few larger I/O operations on the
- servers. This buffering is configurable and gives a mechanism to trade off a small amount of additional latency for better throughput.
- <p>
- Details on <a href="#producerconfigs">configuration</a> and the <a href="#producerapi">api</a> for the producer can be found elsewhere in the documentation.
-
- <h3 class="anchor-heading"><a id="theconsumer" class="anchor-link"></a><a href="#theconsumer">4.5 The Consumer</a></h3>
-
- The Kafka consumer works by issuing "fetch" requests to the brokers leading the partitions it wants to consume. The consumer specifies its offset in the log with each request and receives back a chunk of log
- beginning from that position. The consumer thus has significant control over this position and can rewind it to re-consume data if need be.
-
- <h4 class="anchor-heading"><a id="design_pull" class="anchor-link"></a><a href="#design_pull">Push vs. pull</a></h4>
- <p>
- An initial question we considered is whether consumers should pull data from brokers or brokers should push data to the consumer. In this respect Kafka follows a more traditional design, shared by most messaging
- systems, where data is pushed to the broker from the producer and pulled from the broker by the consumer. Some logging-centric systems, such as <a href="https://github.com/facebook/scribe">Scribe</a> and
- <a href="https://flume.apache.org/">Apache Flume</a>, follow a very different push-based path where data is pushed downstream. There are pros and cons to both approaches. However, a push-based system has difficulty
- dealing with diverse consumers as the broker controls the rate at which data is transferred. The goal is generally for the consumer to be able to consume at the maximum possible rate; unfortunately, in a push
- system this means the consumer tends to be overwhelmed when its rate of consumption falls below the rate of production (a denial of service attack, in essence). A pull-based system has the nicer property that
- the consumer simply falls behind and catches up when it can. This can be mitigated with some kind of backoff protocol by which the consumer can indicate it is overwhelmed, but getting the rate of transfer to
- fully utilize (but never over-utilize) the consumer is trickier than it seems. Previous attempts at building systems in this fashion led us to go with a more traditional pull model.
- <p>
- Another advantage of a pull-based system is that it lends itself to aggressive batching of data sent to the consumer. A push-based system must choose to either send a request immediately or accumulate more data
- and then send it later without knowledge of whether the downstream consumer will be able to immediately process it. If tuned for low latency, this will result in sending a single message at a time only for the
- transfer to end up being buffered anyway, which is wasteful. A pull-based design fixes this as the consumer always pulls all available messages after its current position in the log (or up to some configurable max
- size). So one gets optimal batching without introducing unnecessary latency.
- <p>
- The deficiency of a naive pull-based system is that if the broker has no data the consumer may end up polling in a tight loop, effectively busy-waiting for data to arrive. To avoid this we have parameters in our
- pull request that allow the consumer request to block in a "long poll" waiting until data arrives (and optionally waiting until a given number of bytes is available to ensure large transfer sizes).
- <p>
- You could imagine other possible designs which would be only pull, end-to-end. The producer would locally write to a local log, and brokers would pull from that with consumers pulling from them. A similar type of
- "store-and-forward" producer is often proposed. This is intriguing but we felt not very suitable for our target use cases which have thousands of producers. Our experience running persistent data systems at
- scale led us to feel that involving thousands of disks in the system across many applications would not actually make things more reliable and would be a nightmare to operate. And in practice we have found that we
- can run a pipeline with strong SLAs at large scale without a need for producer persistence.
-
- <h4 class="anchor-heading"><a id="design_consumerposition" class="anchor-link"></a><a href="#design_consumerposition">Consumer Position</a></h4>
- Keeping track of <i>what</i> has been consumed is, surprisingly, one of the key performance points of a messaging system.
- <p>
- Most messaging systems keep metadata about what messages have been consumed on the broker. That is, as a message is handed out to a consumer, the broker either records that fact locally immediately or it may wait
- for acknowledgement from the consumer. This is a fairly intuitive choice, and indeed for a single machine server it is not clear where else this state could go. Since the data structures used for storage in many
- messaging systems scale poorly, this is also a pragmatic choice--since the broker knows what is consumed it can immediately delete it, keeping the data size small.
- <p>
- What is perhaps not obvious is that getting the broker and consumer to come into agreement about what has been consumed is not a trivial problem. If the broker records a message as <b>consumed</b> immediately every
- time it is handed out over the network, then if the consumer fails to process the message (say because it crashes or the request times out or whatever) that message will be lost. To solve this problem, many messaging
- systems add an acknowledgement feature which means that messages are only marked as <b>sent</b> not <b>consumed</b> when they are sent; the broker waits for a specific acknowledgement from the consumer to record the
- message as <b>consumed</b>. This strategy fixes the problem of losing messages, but creates new problems. First of all, if the consumer processes the message but fails before it can send an acknowledgement then the
- message will be consumed twice. The second problem is around performance, now the broker must keep multiple states about every single message (first to lock it so it is not given out a second time, and then to mark
- it as permanently consumed so that it can be removed). Tricky problems must be dealt with, like what to do with messages that are sent but never acknowledged.
- <p>
- Kafka handles this differently. Our topic is divided into a set of totally ordered partitions, each of which is consumed by exactly one consumer within each subscribing consumer group at any given time. This means
- that the position of a consumer in each partition is just a single integer, the offset of the next message to consume. This makes the state about what has been consumed very small, just one number for each partition.
- This state can be periodically checkpointed. This makes the equivalent of message acknowledgements very cheap.
- <p>
- There is a side benefit of this decision. A consumer can deliberately <i>rewind</i> back to an old offset and re-consume data. This violates the common contract of a queue, but turns out to be an essential feature
- for many consumers. For example, if the consumer code has a bug and is discovered after some messages are consumed, the consumer can re-consume those messages once the bug is fixed.
-
- <h4 class="anchor-heading"><a id="design_offlineload" class="anchor-link"></a><a href="#design_offlineload">Offline Data Load</a></h4>
-
- Scalable persistence allows for the possibility of consumers that only periodically consume such as batch data loads that periodically bulk-load data into an offline system such as Hadoop or a relational data
- warehouse.
- <p>
- In the case of Hadoop we parallelize the data load by splitting the load over individual map tasks, one for each node/topic/partition combination, allowing full parallelism in the loading. Hadoop provides the task
- management, and tasks which fail can restart without danger of duplicate data—they simply restart from their original position.
-
- <h4 class="anchor-heading"><a id="static_membership" class="anchor-link"></a><a href="#static_membership">Static Membership</a></h4>
- Static membership aims to improve the availability of stream applications, consumer groups and other applications built on top of the group rebalance protocol.
- The rebalance protocol relies on the group coordinator to allocate entity ids to group members. These generated ids are ephemeral and will change when members restart and rejoin.
- For consumer based apps, this "dynamic membership" can cause a large percentage of tasks re-assigned to different instances during administrative operations
- such as code deploys, configuration updates and periodic restarts. For large state applications, shuffled tasks need a long time to recover their local states before processing
- and cause applications to be partially or entirely unavailable. Motivated by this observation, Kafka’s group management protocol allows group members to provide persistent entity ids.
- Group membership remains unchanged based on those ids, thus no rebalance will be triggered.
- <p>
- If you want to use static membership,
- <ul>
- <li>Upgrade both broker cluster and client apps to 2.3 or beyond, and also make sure the upgraded brokers are using <code>inter.broker.protocol.version</code>
- of 2.3 or beyond as well.</li>
- <li>Set the config <code>ConsumerConfig#GROUP_INSTANCE_ID_CONFIG</code> to a unique value for each consumer instance under one group.</li>
- <li>For Kafka Streams applications, it is sufficient to set a unique <code>ConsumerConfig#GROUP_INSTANCE_ID_CONFIG</code> per KafkaStreams instance,
- independent of the number of used threads for an instance.</li>
- </ul>
- If your broker is on an older version than 2.3, but you choose to set <code>ConsumerConfig#GROUP_INSTANCE_ID_CONFIG</code> on the client side, the application will detect
- the broker version and then throws an UnsupportedException. If you accidentally configure duplicate ids for different instances,
- a fencing mechanism on broker side will inform your duplicate client to shutdown immediately by triggering a <code>org.apache.kafka.common.errors.FencedInstanceIdException</code>.
- For more details, see
- <a href="https://cwiki.apache.org/confluence/x/kRg0BQ">KIP-345</a>
-
- <h3 class="anchor-heading"><a id="semantics" class="anchor-link"></a><a href="#semantics">4.6 Message Delivery Semantics</a></h3>
- <p>
- Now that we understand a little about how producers and consumers work, let's discuss the semantic guarantees Kafka provides between producer and consumer. Clearly there are multiple possible message delivery
- guarantees that could be provided:
- <ul>
- <li>
- <i>At most once</i>—Messages may be lost but are never redelivered.
- </li>
- <li>
- <i>At least once</i>—Messages are never lost but may be redelivered.
- </li>
- <li>
- <i>Exactly once</i>—Each message is processed once and only once.
- </li>
- </ul>
-
- It's worth noting that this breaks down into two problems: the durability guarantees for publishing a message and the guarantees when consuming a message.
- <p>
- Many systems claim to provide "exactly-once" delivery semantics, but it is important to read the fine print, because sometimes these claims are misleading (i.e. they don't translate to the case where consumers or producers
- can fail, cases where there are multiple consumer processes, or cases where data written to disk can be lost).
- <p>
- Kafka's semantics are straightforward. When publishing a message we have a notion of the message being "committed" to the log. A message is considered committed only when all replicas in the in-sync replicas (ISR) for that
- partition have applied it to their log. Once a published message is committed, it will not be lost as long as one broker that replicates the partition to which this message was written remains "alive".
- The definition of committed message and alive partition as well as a description of which types of failures we attempt to handle will be
- described in more detail in the next section. For now let's assume a perfect, lossless broker and try to understand the guarantees to the producer and consumer. If a producer attempts to publish a message and
- experiences a network error, it cannot be sure if this error happened before or after the message was committed. This is similar to the semantics of inserting into a database table with an autogenerated key.
- <p>
- Prior to 0.11.0.0, if a producer failed to receive a response indicating that a message was committed, it had little choice but to resend the message. This provides at-least-once delivery semantics since the
- message may be written to the log again during resending if the original request had in fact succeeded. Since 0.11.0.0, the Kafka producer also supports an idempotent delivery option which guarantees that resending
- will not result in duplicate entries in the log. To achieve this, the broker assigns each producer an ID and deduplicates messages using a sequence number that is sent by the producer along with every message.
- Also beginning with 0.11.0.0, the producer supports the ability to send messages atomically to multiple topic partitions using transactions, so that either all messages are successfully written or none of them are.
- <p>
- Not all use cases require such strong guarantees. For use cases which are latency-sensitive, we allow the producer to specify the durability level it desires. If the producer specifies that it wants to wait on the message
- being committed, this can take on the order of 10 ms. However the producer can also specify that it wants to perform the send completely asynchronously or that it wants to wait only until the leader (but not
- necessarily the followers) have the message.
- <p>
- Now let's describe the semantics from the point of view of the consumer. All replicas have the exact same log with the same offsets. The consumer controls its position in this log. If the consumer never crashed it
- could just store this position in memory, but if the consumer fails and we want this topic partition to be taken over by another process, the new process will need to choose an appropriate position from which to start
- processing. Let's say the consumer reads some messages -- it has several options for processing the messages and updating its position.
- <ol>
- <li>It can read the messages, then save its position in the log, and finally process the messages. In this case there is a possibility that the consumer process crashes after saving its position but before saving
- the output of its message processing. In this case the process that took over processing would start at the saved position even though a few messages prior to that position had not been processed. This corresponds
- to "at-most-once" semantics as in the case of a consumer failure messages may not be processed.
- <li>It can read the messages, process the messages, and finally save its position. In this case there is a possibility that the consumer process crashes after processing messages but before saving its position.
- In this case when the new process takes over the first few messages it receives will already have been processed. This corresponds to the "at-least-once" semantics in the case of consumer failure. In many cases
- messages have a primary key and so the updates are idempotent (receiving the same message twice just overwrites a record with another copy of itself).
- </ol>
- <p>
- So what about exactly-once semantics? When consuming from a Kafka topic and producing to another topic (as in a <a href="https://kafka.apache.org/documentation/streams">Kafka Streams</a> application), we can
- leverage the new transactional producer capabilities in 0.11.0.0 that were mentioned above. The consumer's position is stored as a message in an internal topic, so we can write the offset to Kafka in the
- same transaction as the output topics receiving the processed data. If the transaction is aborted, the consumer's stored position will revert to its old value (although the consumer has to refetch the
- committed offset because it does not automatically rewind) and the produced data on the output topics will not be visible to other consumers, depending on their "isolation level". In the default
- "read_uncommitted" isolation level, all messages are visible to consumers even if they were part of an aborted transaction, but in "read_committed" isolation level, the consumer will only return messages
- from transactions which were committed (and any messages which were not part of a transaction).
- <p>
- When writing to an external system, the limitation is in the need to coordinate the consumer's position with what is actually stored as output. The classic way of achieving this would be to introduce a two-phase
- commit between the storage of the consumer position and the storage of the consumers output. This can be handled more simply and generally by letting the consumer store its offset in the same place as
- its output. This is better because many of the output systems a consumer might want to write to will not support a two-phase commit. As an example of this, consider a
- <a href="https://kafka.apache.org/documentation/#connect">Kafka Connect</a> connector which populates data in HDFS along with the offsets of the data it reads so that it is guaranteed that either data and
- offsets are both updated or neither is. We follow similar patterns for many other data systems which require these stronger semantics and for which the messages do not have a primary key to allow for deduplication.
- <p>
- As a result, Kafka supports exactly-once delivery in <a href="https://kafka.apache.org/documentation/streams">Kafka Streams</a>, and the transactional producer and the consumer using read-committed isolation level
- can be used generally to provide exactly-once delivery when reading, processing and writing data on Kafka topics. Exactly-once delivery for other destination systems generally requires cooperation with such systems,
- but Kafka provides the primitives which makes implementing this feasible (see also <a href="https://kafka.apache.org/documentation/#connect">Kafka Connect</a>). Otherwise, Kafka guarantees at-least-once delivery
- by default, and allows the user to implement at-most-once delivery by disabling retries on the producer and committing offsets in the consumer prior to processing a batch of messages.
-
- <h3 class="anchor-heading"><a id="usingtransactions" class="anchor-link"></a><a href="#usingtransactions">4.7 Using Transactions</a></h3>
- <p>
- As mentioned above, the simplest way to get exactly-once semantics from Kafka is to use <a href="https://kafka.apache.org/documentation/streams">Kafka Streams</a>. However, it is also possible to achieve
- the same transactional guarantees using the Kafka producer and consumer directly by using them in the same way as Kafka Streams does.
- <p>
- Kafka transactions are a bit different from transactions in other messaging systems. In Kafka, the consumer and producer are separate, and it is only the producer which is transactional. It is however able to
- make transactional updates to the consumer's position (confusingly called the "committed offset"), and it is this which gives the overall exactly-once behavior.
- <p>
- There are three key aspects to exactly-once processing using the producer and consumer, which match how Kafka Streams works.
- <ol>
- <li>The consumer uses partition assignment to ensure that it is the only consumer in the consumer group currently processing each partition.</li>
- <li>The producer uses transactions so that all the records it produces, and any offsets it updates on behalf of the consumer, are performed atomically.</li>
- <li>In order to handle transactions properly in combination with rebalancing, it is advisable to use one producer instance for each consumer instance. More complicated and efficient schemes are possible,
- but at the cost of greater complexity.</li>
- </ol>
- <p>
- In addition, it is generally considered a good practice to use the read-committed isolation level if trying to achieve exactly-once processing. Strictly speaking, the consumer doesn't have to use read-committed
- isolation level, but if it does not, it will see records from aborted transactions and also open transactions which have not yet completed.
- <p>
- The consumer configuration must include <code>isolation.level=read_committed</code> and <code>enable.auto.commit=false</code>. The producer configuration must set <code>transactional.id</code>
- to the name of the transactional ID to be used, which configures the producer for transactional delivery and also makes sure that a restarted application causes any in-flight transaction from
- the previous instance to abort. Only the producer has the <code>transactional.id</code> configuration.
- <p>
- Here's an example of a <a href="https://github.com/apache/kafka/blob/trunk/tools/src/main/java/org/apache/kafka/tools/TransactionalMessageCopier.java">transactional message copier</a>
- which uses these principles. It uses a <code>KafkaConsumer</code> to consume records from one topic and a <code>KafkaProducer</code> to produce records to another topic. It uses transactions to ensure
- that there is no duplication or loss of records as they are copied, provided that the <code>--use-group-metadata</code> option is set.
- <p>
- It is important to handle exceptions and aborted transactions correctly. Any records written by the transactional producer will be marked as being part of the transactions, and then when the
- transaction commits or aborts, transaction marker records are written to indicate the outcome of the transaction. This is how the read-committed consumer does not see records from aborted
- transactions. However, in the event of a transaction abort, the application's state and in particular the current position of the consumer must be reset explicitly so that it can
- reprocess the records processed by the aborted transaction.
- <p>
- The error handling for transactional producer has been standardized which ensures consistent behavior and clearer error handling patterns. The exception categories are now more precisely defined:
- <ol>
- <li><strong>RetriableException</strong>: Temporary exceptions that are retried automatically by the client. These are handled internally and don't bubble up to the application.</li>
- <li><strong>RefreshRetriableException</strong>: Exceptions requiring metadata refresh before retry. These are handled internally by the client after refreshing metadata and don't bubble up to the application.</li>
- <li><strong>AbortableException</strong>: Exceptions that require transaction abort and reprocessing. These bubble up to the application, which must handle them by aborting the transaction and resetting the consumer position.</li>
- <li><strong>ApplicationRecoverableException</strong>: Exceptions that bubble up to the application and require application handling. The application must implement its own recovery strategy, which must include restarting the producer.</li>
- <li><strong>InvalidConfigurationException</strong>: Configuration-related exceptions that bubble up to the application and require application handling. The producer doesn't need to restart, but the application may choose to restart it.</li>
- <li><strong>KafkaException</strong>: General Kafka exceptions that don't fit into the above categories. These bubble up to the application for handling.</li>
- </ol>
- <p>
- Example template code for handling transaction exceptions link : <a href="https://github.com/apache/kafka/blob/trunk/examples/src/main/java/kafka/examples/TransactionalClientDemo.java"> Transaction Client Demo</a>
- <p>
- A simple policy for handling exceptions and aborted transactions is to discard and recreate the Kafka producer and consumer objects and start afresh. As part of recreating the consumer, the consumer
- group will rebalance and fetch the last committed offset, which has the effect of rewinding back to the state before the transaction aborted. Alternatively, a more sophisticated application (such as the
- transactional message copier) can choose not to use <code>KafkaConsumer.committed</code> to retrieve the committed offset from Kafka, and then <code>KafkaConsumer.seek</code> to rewind the current position.
-
- <h3 class="anchor-heading"><a id="theshareconsumer" class="anchor-link"></a><a href="#theshareconsumer">4.8 The Share Consumer</a></h3>
- <p>
- Most consumption of data from Kafka is performed by consumers in consumer groups. The way that consumer groups assign partitions to members of the group gives a powerful combination of ordering
- and scalability. However, some traditional messaging workloads are not a good fit for consumer groups.
- <p>
- Share groups are another type of group, existing alongside traditional consumer groups. They offer an alternative to consumer groups, particularly when applications require finer-grained sharing of partitions and records.
- Share groups enable consumers to cooperatively consume and process records from topics. The consumers in a share group are called share consumers, and they use a familiar but different programming interface.
- <p>
- The fundamental differences between a share group and a consumer group are:
- <ul>
- <li>The consumers in a share group cooperatively consume records, and partitions may be assigned to multiple consumers.</li>
- <li>The number of consumers in a share group can exceed the number of partitions in a topic.</li>
- <li>Records are acknowledged individually, though the system is optimized for batch processing to improve efficiency.</li>
- <li>Delivery attempts to consumers in a share group are counted, which enables automated handling of unprocessable records.</li>
- </ul>
- <p>
- All share consumers in the same share group subscribed to the same topic will cooperatively consume the records of that topic. If a topic is accessed by consumers in multiple share groups, each share group
- consumes from that topic independently of the others.
- <p>
- Each share consumer can dynamically set its list of subscribed topics. In practice, all consumers in a share group typically subscribe to the same topic or topics.
- <p>
- When a share consumer fetches records, it receives available records from any of the topic-partitions matching its subscriptions. Records are acquired for delivery to this share consumer with a time-limited
- acquisition lock. While a record is acquired, it is unavailable to other consumers in the same share group for the duration of the lock.
- <p>
- By default, the lock duration is 30 seconds, but you can control it using the group configuration parameter <code>share.record.lock.duration.ms</code>. The lock is released automatically once its
- duration elapses, making the record available to another delivery attempt. A share consumer holding the lock can handle the record in the following ways:
- <ul>
- <li>Acknowledge successful processing of the record.</li>
- <li>Release the record, making it available for another delivery attempt.</li>
- <li>Reject the record, indicating it's unprocessable and preventing further delivery attempts for that record.</li>
- <li>Renew the record, extending the delivery attempt because the record is still being processed.</li>
- <li>Do nothing, in which case the lock is automatically released when its duration elapses.</li>
- </ul>
- <p>
- The Kafka cluster limits the number of records for each topic-partition acquired by share consumers in each share group. Once this limit is reached, fetching operations will temporarily yield no further records
- until the number of acquired records decreases (as locks naturally time out). This limit is controlled by the broker configuration property <code>group.share.partition.max.record.locks</code>. By limiting
- the duration of the acquisition lock and automatically releasing the locks, the broker ensures delivery progresses even in the presence of consumer failures.
-
- <h3 class="anchor-heading"><a id="replication" class="anchor-link"></a><a href="#replication">4.9 Replication</a></h3>
- <p>
- Kafka replicates the log for each topic's partitions across a configurable number of servers (you can set this replication factor on a topic-by-topic basis). This allows automatic failover to these replicas when a
- server in the cluster fails so messages remain available in the presence of failures.
- <p>
- Other messaging systems provide some replication-related features, but, in our (totally biased) opinion, this appears to be a tacked-on thing, not heavily used, and with large downsides: replicas are inactive,
- throughput is heavily impacted, it requires fiddly manual configuration, etc. Kafka is meant to be used with replication by default—in fact we implement un-replicated topics as replicated topics where the
- replication factor is one.
- <p>
- The unit of replication is the topic partition. Under non-failure conditions, each partition in Kafka has a single leader and zero or more followers. The total number of replicas including the leader constitute the
- replication factor. All writes go to the leader of the partition, and reads can go to the leader or the followers of the partition. Typically, there are many more partitions than brokers and the leaders are evenly distributed among brokers. The logs on the followers are
- identical to the leader's log—all have the same offsets and messages in the same order (though, of course, at any given time the leader may have a few as-yet unreplicated messages at the end of its log).
- <p>
- Followers consume messages from the leader just as a normal Kafka consumer would and apply them to their own log. Having the followers pull from the leader has the nice property of allowing the follower to naturally
- batch together log entries they are applying to their log.
- <p>
- As with most distributed systems, automatically handling failures requires a precise definition of what it means for a node to be "alive." In Kafka, a special node
- known as the "controller" is responsible for managing the registration of brokers in the cluster. Broker liveness has two conditions:
- <ol>
- <li>Brokers must maintain an active session with the controller in order to receive regular metadata updates.</li>
- <li>Brokers acting as followers must replicate the writes from the leader and not fall "too far" behind.</li>
- </ol>
- <p>
- What is meant by an "active session" depends on the cluster configuration. For KRaft clusters, an active session is maintained by
- sending periodic heartbeats to the controller. If the controller fails to receive a heartbeat before the timeout configured by
- <code>broker.session.timeout.ms</code> expires, then the node is considered offline.
- <p>
- We refer to nodes satisfying these two conditions as being "in sync" to avoid the vagueness of "alive" or "failed". The leader keeps track of the set of "in sync" replicas,
- which is known as the ISR. If either of these conditions fail to be satisfied, then the broker will be removed from the ISR. For example,
- if a follower dies, then the controller will notice the failure through the loss of its session, and will remove the broker from the ISR.
- On the other hand, if the follower lags too far behind the leader but still has an active session, then the leader can also remove it from the ISR.
- The determination of lagging replicas is controlled through the <code>replica.lag.time.max.ms</code> configuration.
- Replicas that cannot catch up to the end of the log on the leader within the max time set by this configuration are removed from the ISR.
- <p>
- In distributed systems terminology we only attempt to handle a "fail/recover" model of failures where nodes suddenly cease working and then later recover (perhaps without knowing that they have died). Kafka does not
- handle so-called "Byzantine" failures in which nodes produce arbitrary or malicious responses (perhaps due to bugs or foul play).
- <p>
- 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 <code>acks</code> setting that the
- producer uses.
- 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>
- Kafka will remain available in the presence of node failures after a short fail-over period, but may not remain available in the presence of network partitions.
-
- <h4><a id="design_replicatedlog" href="#design_replicatedlog">Replicated Logs: Quorums, ISRs, and State Machines (Oh my!)</a></h4>
-
- At its heart a Kafka partition is a replicated log. The replicated log is one of the most basic primitives in distributed data systems, and there are many approaches for implementing one. A replicated log can be
- used by other systems as a primitive for implementing other distributed systems in the <a href="https://en.wikipedia.org/wiki/State_machine_replication">state-machine style</a>.
- <p>
- A replicated log models the process of coming into consensus on the order of a series of values (generally numbering the log entries 0, 1, 2, ...). There are many ways to implement this, but the simplest and fastest
- is with a leader who chooses the ordering of values provided to it. As long as the leader remains alive, all followers need to only copy the values and ordering the leader chooses.
- <p>
- Of course if leaders didn't fail we wouldn't need followers! When the leader does die we need to choose a new leader from among the followers. But followers themselves may fall behind or crash so we must ensure we
- choose an up-to-date follower. The fundamental guarantee a log replication algorithm must provide is that if we tell the client a message is committed, and the leader fails, the new leader we elect must also have
- that message. This yields a tradeoff: if the leader waits for more followers to acknowledge a message before declaring it committed then there will be more potentially electable leaders.
- <p>
- If you choose the number of acknowledgements required and the number of logs that must be compared to elect a leader such that there is guaranteed to be an overlap, then this is called a Quorum.
- <p>
- A common approach to this tradeoff is to use a majority vote for both the commit decision and the leader election. This is not what Kafka does, but let's explore it anyway to understand the tradeoffs. Let's say we
- have 2<i>f</i>+1 replicas. If <i>f</i>+1 replicas must receive a message prior to a commit being declared by the leader, and if we elect a new leader by electing the follower with the most complete log from at least
- <i>f</i>+1 replicas, then, with no more than <i>f</i> failures, the leader is guaranteed to have all committed messages. This is because among any <i>f</i>+1 replicas, there must be at least one replica that contains
- all committed messages. That replica's log will be the most complete and therefore will be selected as the new leader. There are many remaining details that each algorithm must handle (such as precisely defined what
- makes a log more complete, ensuring log consistency during leader failure or changing the set of servers in the replica set) but we will ignore these for now.
- <p>
- This majority vote approach has a very nice property: the latency is dependent on only the fastest servers. That is, if the replication factor is three, the latency is determined by the faster follower not the slower one.
- <p>
- There are a rich variety of algorithms in this family including ZooKeeper's
- <a href="https://web.archive.org/web/20140602093727/https://www.stanford.edu/class/cs347/reading/zab.pdf">Zab</a>,
- <a href="https://www.usenix.org/system/files/conference/atc14/atc14-paper-ongaro.pdf">Raft</a>,
- and <a href="https://pmg.csail.mit.edu/papers/vr-revisited.pdf">Viewstamped Replication</a>.
- The most similar academic publication we are aware of to Kafka's actual implementation is
- <a href="https://research.microsoft.com/apps/pubs/default.aspx?id=66814">PacificA</a> from Microsoft.
- <p>
- The downside of majority vote is that it doesn't take many failures to leave you with no electable leaders. To tolerate one failure requires three copies of the data, and to tolerate two failures requires five copies
- of the data. In our experience having only enough redundancy to tolerate a single failure is not enough for a practical system, but doing every write five times, with 5x the disk space requirements and 1/5th the
- throughput, is not very practical for large volume data problems. This is likely why quorum algorithms more commonly appear for shared cluster configuration such as ZooKeeper but are less common for primary data
- storage. For example in HDFS the namenode's high-availability feature is built on a <a href="https://blog.cloudera.com/blog/2012/10/quorum-based-journaling-in-cdh4-1">majority-vote-based journal</a>, but this more
- expensive approach is not used for the data itself.
- <p>
- Kafka takes a slightly different approach to choosing its quorum set. Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. Only members of this set
- are eligible for election as leader. A write to a Kafka partition is not considered committed until <i>all</i> in-sync replicas have received the write. This ISR set is persisted in the cluster metadata whenever it changes.
- Because of this, any replica in the ISR is eligible to be elected leader. This is an important factor for Kafka's usage model where there are many partitions and ensuring leadership balance is important.
- With this ISR model and <i>f+1</i> replicas, a Kafka topic can tolerate <i>f</i> failures without losing committed messages.
- <p>
- For most use cases we hope to handle, we think this tradeoff is a reasonable one. In practice, to tolerate <i>f</i> failures, both the majority vote and the ISR approach will wait for the same number of replicas to
- acknowledge before committing a message (e.g. to survive one failure a majority quorum needs three replicas and one acknowledgement and the ISR approach requires two replicas and one acknowledgement).
- The ability to commit without the slowest servers is an advantage of the majority vote approach. However, we think it is ameliorated by allowing the client to choose whether they block on the message commit or not,
- and the additional throughput and disk space due to the lower required replication factor is worth it.
- <p>
- Another important design distinction is that Kafka does not require that crashed nodes recover with all their data intact. It is not uncommon for replication algorithms in this space to depend on the existence of
- "stable storage" that cannot be lost in any failure-recovery scenario without potential consistency violations. There are two primary problems with this assumption. First, disk errors are the most common problem we
- observe in real operation of persistent data systems and they often do not leave data intact. Secondly, even if this were not a problem, we do not want to require the use of fsync on every write for our consistency
- guarantees as this can reduce performance by two to three orders of magnitude. Our protocol for allowing a replica to rejoin the ISR ensures that before rejoining, it must fully re-sync again even if it lost unflushed
- data in its crash.
-
- <h4><a id="design_uncleanleader" href="#design_uncleanleader">Unclean leader election: What if they all die?</a></h4>
-
- Note that Kafka's guarantee with respect to data loss is predicated on at least one replica remaining in sync. If all the nodes replicating a partition die, this guarantee no longer holds.
- <p>
- However a practical system needs to do something reasonable when all the replicas die. If you are unlucky enough to have this occur, it is important to consider what will happen. There are two behaviors that could be
- implemented:
- <ol>
- <li>Wait for a replica in the ISR to come back to life and choose this replica as the leader (hopefully it still has all its data).
- <li>Choose the first replica (not necessarily in the ISR) that comes back to life as the leader.
- </ol>
- <p>
- This is a simple tradeoff between availability and consistency. If we wait for replicas in the ISR, then we will remain unavailable as long as those replicas are down. If such replicas were destroyed or their data
- was lost, then we are permanently down. If, on the other hand, a non-in-sync replica comes back to life and we allow it to become leader, then its log becomes the source of truth even though it is not guaranteed to
- have every committed message. By default from version 0.11.0.0, Kafka chooses the first strategy and favor waiting for a consistent replica. This behavior can be changed using
- configuration property <code>unclean.leader.election.enable</code>, to support use cases where uptime is preferable to consistency.
- <p>
- This dilemma is not specific to Kafka. It exists in any quorum-based scheme. For example in a majority voting scheme, if a majority of servers suffer a permanent failure, then you must either choose to lose 100% of
- your data or violate consistency by taking what remains on an existing server as your new source of truth.
-
-
- <h4 class="anchor-heading"><a id="design_ha" class="anchor-link"></a><a href="#design_ha">Availability and Durability Guarantees</a></h4>
-
- When writing to Kafka, producers can choose whether they wait for the message to be acknowledged by 0,1 or all (-1) replicas.
- Note that "acknowledgement by all replicas" does not guarantee that the full set of assigned replicas have received the message. By default, when acks=all, acknowledgement happens as soon as all the current in-sync
- replicas have received the message. For example, if a topic is configured with only two replicas and one fails (i.e., only one in sync replica remains), then writes that specify acks=all will succeed. However, these
- writes could be lost if the remaining replica also fails.
-
- Although this ensures maximum availability of the partition, this behavior may be undesirable to some users who prefer durability over availability. Therefore, we provide two topic configurations that can be
- used to prefer message durability over availability:
- <ol>
- <li> Disable unclean leader election - if all replicas become unavailable, then the partition will remain unavailable until the most recent leader becomes available again. This effectively prefers unavailability
- over the risk of message loss. See the previous section on Unclean Leader Election for clarification. </li>
- <li> Specify a minimum ISR size - the partition will only accept writes if the size of the ISR is above a certain minimum, in order to prevent the loss of messages that were written to just a single replica,
- which subsequently becomes unavailable. This setting only takes effect if the producer uses acks=all and guarantees that the message will be acknowledged by at least this many in-sync replicas.
- This setting offers a trade-off between consistency and availability. A higher setting for minimum ISR size guarantees better consistency since the message is guaranteed to be written to more replicas which reduces
- the probability that it will be lost. However, it reduces availability since the partition will be unavailable for writes if the number of in-sync replicas drops below the minimum threshold. </li>
- </ol>
-
-
- <h4 class="anchor-heading"><a id="design_replicamanagment" class="anchor-link"></a><a href="#design_replicamanagment">Replica Management</a></h4>
-
- The above discussion on replicated logs really covers only a single log, i.e. one topic partition. However a Kafka cluster will manage hundreds or thousands of these partitions. We attempt to balance partitions
- within a cluster in a round-robin fashion to avoid clustering all partitions for high-volume topics on a small number of nodes. Likewise we try to balance leadership so that each node is the leader for a proportional
- share of its partitions.
- <p>
- It is also important to optimize the leadership election process as that is the critical window of unavailability. A naive implementation of leader election would end up running an election per partition for all
- partitions a node hosted when that node failed. As discussed above in the section on <a href="#replication">replication</a>, Kafka clusters have a special role known as the "controller" which is
- responsible for managing the registration of brokers. If the controller detects the failure of a broker, it is responsible for electing one of the remaining members of the ISR to serve as the new leader.
- The result is that we are able to batch together many of the required leadership change notifications which makes the election process far cheaper and faster for a large number
- of partitions. If the controller itself fails, then another controller will be elected.
-
- <h3 class="anchor-heading"><a id="compaction" class="anchor-link"></a><a href="#compaction">4.10 Log Compaction</a></h3>
-
- Log compaction ensures that Kafka will always retain at least the last known value for each message key within the log of data for a single topic partition. It addresses use cases and scenarios such as restoring
- state after application crashes or system failure, or reloading caches after application restarts during operational maintenance. Let's dive into these use cases in more detail and then describe how compaction works.
- <p>
- So far we have described only the simpler approach to data retention where old log data is discarded after a fixed period of time or when the log reaches some predetermined size. This works well for temporal event
- data such as logging where each record stands alone. However an important class of data streams are the log of changes to keyed, mutable data (for example, the changes to a database table).
- <p>
- Let's discuss a concrete example of such a stream. Say we have a topic containing user email addresses; every time a user updates their email address we send a message to this topic using their user id as the
- primary key. Now say we send the following messages over some time period for a user with id 123, each message corresponding to a change in email address (messages for other ids are omitted):
- <pre class="line-numbers"><code class="language-text">123 => bill@microsoft.com
- .
- .
- .
-123 => bill@gatesfoundation.org
- .
- .
- .
-123 => bill@gmail.com</code></pre>
- Log compaction gives us a more granular retention mechanism so that we are guaranteed to retain at least the last update for each primary key (e.g. <code>bill@gmail.com</code>). By doing this we guarantee that the
- log contains a full snapshot of the final value for every key not just keys that changed recently. This means downstream consumers can restore their own state off this topic without us having to retain a complete
- log of all changes.
- <p>
- Let's start by looking at a few use cases where this is useful, then we'll see how it can be used.
- <ol>
- <li><i>Database change subscription</i>. It is often necessary to have a data set in multiple data systems, and often one of these systems is a database of some kind (either a RDBMS or perhaps a new-fangled key-value
- store). For example you might have a database, a cache, a search cluster, and a Hadoop cluster. Each change to the database will need to be reflected in the cache, the search cluster, and eventually in Hadoop.
- In the case that one is only handling the real-time updates you only need recent log. But if you want to be able to reload the cache or restore a failed search node you may need a complete data set.
- <li><i>Event sourcing</i>. This is a style of application design which co-locates query processing with application design and uses a log of changes as the primary store for the application.
- <li><i>Journaling for high-availability</i>. A process that does local computation can be made fault-tolerant by logging out changes that it makes to its local state so another process can reload these changes and
- carry on if it should fail. A concrete example of this is handling counts, aggregations, and other "group by"-like processing in a stream query system. Samza, a real-time stream-processing framework,
- <a href="https://samza.apache.org/learn/documentation/0.7.0/container/state-management.html">uses this feature</a> for exactly this purpose.
- </ol>
- In each of these cases one needs primarily to handle the real-time feed of changes, but occasionally, when a machine crashes or data needs to be re-loaded or re-processed, one needs to do a full load.
- Log compaction allows feeding both of these use cases off the same backing topic.
-
- This style of usage of a log is described in more detail in <a href="https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying">this blog post</a>.
- <p>
- The general idea is quite simple. If we had infinite log retention, and we logged each change in the above cases, then we would have captured the state of the system at each time from when it first began.
- Using this complete log, we could restore to any point in time by replaying the first N records in the log. This hypothetical complete log is not very practical for systems that update a single record many times
- as the log will grow without bound even for a stable dataset. The simple log retention mechanism which throws away old updates will bound space but the log is no longer a way to restore the current state—now
- restoring from the beginning of the log no longer recreates the current state as old updates may not be captured at all.
- <p>
- Log compaction is a mechanism to give finer-grained per-record retention, rather than the coarser-grained time-based retention. The idea is to selectively remove records where we have a more recent update with the
- same primary key. This way the log is guaranteed to have at least the last state for each key.
- <p>
- This retention policy can be set per-topic, so a single cluster can have some topics where retention is enforced by size or time and other topics where retention is enforced by compaction.
- <p>
- This functionality is inspired by one of LinkedIn's oldest and most successful pieces of infrastructure—a database changelog caching service called <a href="https://github.com/linkedin/databus">Databus</a>.
- Unlike most log-structured storage systems Kafka is built for subscription and organizes data for fast linear reads and writes. Unlike Databus, Kafka acts as a source-of-truth store so it is useful even in
- situations where the upstream data source would not otherwise be replayable.
-
- <h4 class="anchor-heading"><a id="design_compactionbasics" class="anchor-link"></a><a href="#design_compactionbasics">Log Compaction Basics</a></h4>
-
- Here is a high-level picture that shows the logical structure of a Kafka log with the offset for each message.
- <p>
- <img class="centered" src="/{{version}}/images/log_cleaner_anatomy.png">
- <p>
- The head of the log is identical to a traditional Kafka log. It has dense, sequential offsets and retains all messages. Log compaction adds an option for handling the tail of the log. The picture above shows a log
- with a compacted tail. Note that the messages in the tail of the log retain the original offset assigned when they were first written—that never changes. Note also that all offsets remain valid positions in
- the log, even if the message with that offset has been compacted away; in this case this position is indistinguishable from the next highest offset that does appear in the log. For example, in the picture above the
- offsets 36, 37, and 38 are all equivalent positions and a read beginning at any of these offsets would return a message set beginning with 38.
- <p>
- Compaction also allows for deletes. A message with a key and a null payload will be treated as a delete from the log. Such a record is sometimes referred to as a <i>tombstone</i>. This delete marker will cause any prior message with that key to be removed (as would any new
- message with that key), but delete markers are special in that they will themselves be cleaned out of the log after a period of time to free up space. The point in time at which deletes are no longer retained is
- marked as the "delete retention point" in the above diagram.
- <p>
- The compaction is done in the background by periodically recopying log segments. Cleaning does not block reads and can be throttled to use no more than a configurable amount of I/O throughput to avoid impacting
- producers and consumers. The actual process of compacting a log segment looks something like this:
- <p>
- <img class="centered" src="/{{version}}/images/log_compaction.png">
- <p>
- <h4 class="anchor-heading">
- <a class="anchor-link" id="design_compactionguarantees" href="#design_compactionguarantees"></a>
- <a href="#design_compactionguarantees">What guarantees does log compaction provide</a>?
- </h4>
-
- Log compaction guarantees the following:
- <ol>
- <li>Any consumer that stays caught-up to within the head of the log will see every message that is written; these messages will have sequential offsets. The topic's <code>min.compaction.lag.ms</code> can be used to
- guarantee the minimum length of time must pass after a message is written before it could be compacted, that is, it provides a lower bound on how long each message will remain in the (uncompacted) head.
- The topic's <code>max.compaction.lag.ms</code> can be used to guarantee the maximum delay between the time a message is written and the time the message becomes eligible for compaction.
- <li>Ordering of messages is always maintained. Compaction will never re-order messages, just remove some.
- <li>The offset for a message never changes. It is the permanent identifier for a position in the log.
- <li>Any consumer progressing from the start of the log will see at least the final state of all records in the order they were written. Additionally, all delete markers for deleted records will be seen, provided
- the consumer reaches the head of the log in a time period less than the topic's <code>delete.retention.ms</code> setting (the default is 24 hours). In other words: since the removal of delete markers happens
- concurrently with reads, it is possible for a consumer to miss delete markers if it lags by more than <code>delete.retention.ms</code>.
- </ol>
-
- <h4 class="anchor-heading"><a id="design_compactiondetails" class="anchor-link"></a><a href="#design_compactiondetails">Log Compaction Details</a></h4>
-
- Log compaction is handled by the log cleaner, a pool of background threads that recopy log segment files, removing records whose key appears in the head of the log. Each compactor thread works as follows:
- <ol>
- <li>It chooses the log that has the highest ratio of log head to log tail
- <li>It creates a succinct summary of the last offset for each key in the head of the log
- <li>It recopies the log from beginning to end removing keys which have a later occurrence in the log. New, clean segments are swapped into the log immediately so the additional disk space required is just one
- additional log segment (not a full copy of the log).
- <li>The summary of the log head is essentially just a space-compact hash table. It uses exactly 24 bytes per entry. As a result with 8GB of cleaner buffer one cleaner iteration can clean around 366GB of log head
- (assuming 1kB messages).
- </ol>
- <p>
- <h4 class="anchor-heading"><a id="design_compactionconfig" class="anchor-link"></a><a href="#design_compactionconfig">Configuring The Log Cleaner</a></h4>
-
- The log cleaner is enabled by default. This will start the pool of cleaner threads.
- To enable log cleaning on a particular topic, add the log-specific property
- <pre class="language-text"><code>log.cleanup.policy=compact</code></pre>
-
- The <code>log.cleanup.policy</code> property is a broker configuration setting defined
- in the broker's <code>server.properties</code> file; it affects all of the topics
- in the cluster that do not have a configuration override in place as documented
- <a href="/documentation.html#brokerconfigs">here</a>.
-
- The log cleaner can be configured to retain a minimum amount of the uncompacted "head" of the log. This is enabled by setting the compaction time lag.
- <pre class="language-text"><code>log.cleaner.min.compaction.lag.ms</code></pre>
-
- This can be used to prevent messages newer than a minimum message age from being subject to compaction. If not set, all log segments are eligible for compaction except for the last segment, i.e. the one currently
- being written to. The active segment will not be compacted even if all of its messages are older than the minimum compaction time lag.
-
- The log cleaner can be configured to ensure a maximum delay after which the uncompacted "head" of the log becomes eligible for log compaction.
- <pre class="language-text"><code>log.cleaner.max.compaction.lag.ms</code></pre>
-
- This can be used to prevent log with low produce rate from remaining ineligible for compaction for an unbounded duration. If not set, logs that do not exceed min.cleanable.dirty.ratio are not compacted.
- Note that this compaction deadline is not a hard guarantee since it is still subjected to the availability of log cleaner threads and the actual compaction time.
- You will want to monitor the uncleanable-partitions-count, max-clean-time-secs and max-compaction-delay-secs metrics.
-
- <p>
- Further cleaner configurations are described <a href="/documentation.html#brokerconfigs">here</a>.
-
- <h3 class="anchor-heading"><a id="design_quotas" class="anchor-link"></a><a href="#design_quotas">4.11 Quotas</a></h3>
- <p>
- Kafka cluster has the ability to enforce quotas on requests to control the broker resources used by clients. Two types
- of client quotas can be enforced by Kafka brokers for each group of clients sharing a quota:
- </p>
- <ol>
- <li>Network bandwidth quotas define byte-rate thresholds (since 0.9)</li>
- <li>Request rate quotas define CPU utilization thresholds as a percentage of network and I/O threads (since 0.11)</li>
- </ol>
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="design_quotasnecessary" href="#design_quotasnecessary"></a>
- <a href="#design_quotasnecessary">Why are quotas necessary</a>?
- </h4>
- <p>
- It is possible for producers and consumers to produce/consume very high volumes of data or generate requests at a very high
- rate and thus monopolize broker resources, cause network saturation and generally DOS other clients and the brokers themselves.
- Having quotas protects against these issues and is all the more important in large multi-tenant clusters where a small set of badly behaved clients can degrade user experience for the well behaved ones.
- In fact, when running Kafka as a service this even makes it possible to enforce API limits according to an agreed upon contract.
- </p>
- <h4 class="anchor-heading"><a id="design_quotasgroups" class="anchor-link"></a><a href="#design_quotasgroups">Client groups</a></h4>
- The identity of Kafka clients is the user principal which represents an authenticated user in a secure cluster. In a cluster that supports unauthenticated clients, user principal is a grouping of unauthenticated
- users
- chosen by the broker using a configurable <code>PrincipalBuilder</code>. Client-id is a logical grouping of clients with a meaningful name chosen by the client application. The tuple (user, client-id) defines
- a secure logical group of clients that share both user principal and client-id.
- <p>
- Quotas can be applied to (user, client-id), user or client-id groups. For a given connection, the most specific quota matching the connection is applied. All connections of a quota group share the quota configured for the group.
- For example, if (user="test-user", client-id="test-client") has a produce quota of 10MB/sec, this is shared across all producer instances of user "test-user" with the client-id "test-client".
- </p>
- <h4 class="anchor-heading"><a id="design_quotasconfig" class="anchor-link"></a><a href="#design_quotasconfig">Quota Configuration</a></h4>
- <p>
- Quota configuration may be defined for (user, client-id), user and client-id groups. It is possible to override the default quota at any of the quota levels that needs a higher (or even lower) quota.
- The mechanism is similar to the per-topic log config overrides.
- User and (user, client-id) quota overrides are written to the metadata log.
- These overrides are read by all brokers and are effective immediately. This lets us change quotas without having to do a rolling restart of the entire cluster. See <a href="#quotas">here</a> for details.
- Default quotas for each group may also be updated dynamically using the same mechanism.
- </p>
- <p>
- The order of precedence for quota configuration is:
- </p>
- <ol>
- <li>matching user and client-id quotas</li>
- <li>matching user and default client-id quotas</li>
- <li>matching user quota</li>
- <li>default user and matching client-id quotas</li>
- <li>default user and default client-id quotas</li>
- <li>default user quota</li>
- <li>matching client-id quota</li>
- <li>default client-id quota</li>
- </ol>
- <h4 class="anchor-heading"><a id="design_quotasbandwidth" class="anchor-link"></a><a href="#design_quotasbandwidth">Network Bandwidth Quotas</a></h4>
- <p>
- Network bandwidth quotas are defined as the byte rate threshold for each group of clients sharing a quota.
- By default, each unique client group receives a fixed quota in bytes/sec as configured by the cluster.
- This quota is defined on a per-broker basis. Each group of clients can publish/fetch a maximum of X bytes/sec
- per broker before clients are throttled.
- </p>
- <h4 class="anchor-heading"><a id="design_quotascpu" class="anchor-link"></a><a href="#design_quotascpu">Request Rate Quotas</a></h4>
- <p>
- Request rate quotas are defined as the percentage of time a client can utilize on request handler I/O
- threads and network threads of each broker within a quota window. A quota of <code>n%</code> represents
- <code>n%</code> of one thread, so the quota is out of a total capacity of <code>((num.io.threads + num.network.threads) * 100)%</code>.
- Each group of clients may use a total percentage of upto <code>n%</code> across all I/O and network threads in a quota
- window before being throttled. Since the number of threads allocated for I/O and network threads are typically based
- on the number of cores available on the broker host, request rate quotas represent the total percentage of CPU
- that may be used by each group of clients sharing the quota.
- </p>
- <h4 class="anchor-heading"><a id="design_quotasenforcement" class="anchor-link"></a><a href="#design_quotasenforcement">Enforcement</a></h4>
- <p>
- By default, each unique client group receives a fixed quota as configured by the cluster.
- This quota is defined on a per-broker basis. Each client can utilize this quota per broker before it gets throttled. We decided that defining these quotas per broker is much better than
- having a fixed cluster wide bandwidth per client because that would require a mechanism to share client quota usage among all the brokers. This can be harder to get right than the quota implementation itself!
- </p>
- <p>
- How does a broker react when it detects a quota violation? In our solution, the broker first computes the amount of delay needed to bring the violating client under its quota
- and returns a response with the delay immediately. In case of a fetch request, the response will not contain any data. Then, the broker mutes the channel to the client,
- not to process requests from the client anymore, until the delay is over. Upon receiving a response with a non-zero delay duration, the Kafka client will also refrain from
- sending further requests to the broker during the delay. Therefore, requests from a throttled client are effectively blocked from both sides.
- Even with older client implementations that do not respect the delay response from the broker, the back pressure applied by the broker via muting its socket channel
- can still handle the throttling of badly behaving clients. Those clients who sent further requests to the throttled channel will receive responses only after the delay is over.
- </p>
- <p>
- Byte-rate and thread utilization are measured over multiple small windows (e.g. 30 windows of 1 second each) in order to detect and correct quota violations quickly. Typically, having large measurement windows
- (for e.g. 10 windows of 30 seconds each) leads to large bursts of traffic followed by long delays which is not great in terms of user experience.
- </p>
-</script>
-
-<div class="p-design"></div>
diff --git a/docs/documentation/streams/index.html b/docs/design/_index.md
similarity index 87%
rename from docs/documentation/streams/index.html
rename to docs/design/_index.md
index 5ff3b3b6fbe..43b243938d7 100644
--- a/docs/documentation/streams/index.html
+++ b/docs/design/_index.md
@@ -1,3 +1,13 @@
+---
+title: Design
+description:
+weight: 4
+tags: ['kafka', 'docs', 'design']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,5 +25,4 @@
limitations under the License.
-->
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../streams/index.html" -->
+
diff --git a/docs/design/design.md b/docs/design/design.md
new file mode 100644
index 00000000000..01c83590a58
--- /dev/null
+++ b/docs/design/design.md
@@ -0,0 +1,507 @@
+---
+title: Design
+description:
+weight: 1
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## Motivation
+
+We designed Kafka to be able to act as a unified platform for handling all the real-time data feeds a large company might have. To do this we had to think through a fairly broad set of use cases.
+
+It would have to have high-throughput to support high volume event streams such as real-time log aggregation.
+
+It would need to deal gracefully with large data backlogs to be able to support periodic data loads from offline systems.
+
+It also meant the system would have to handle low-latency delivery to handle more traditional messaging use-cases.
+
+We wanted to support partitioned, distributed, real-time processing of these feeds to create new, derived feeds. This motivated our partitioning and consumer model.
+
+Finally in cases where the stream is fed into other data systems for serving, we knew the system would have to be able to guarantee fault-tolerance in the presence of machine failures.
+
+Supporting these uses led us to a design with a number of unique elements, more akin to a database log than a traditional messaging system. We will outline some elements of the design in the following sections.
+
+## Persistence
+
+### Don't fear the filesystem!
+
+Kafka relies heavily on the filesystem for storing and caching messages. There is a general perception that "disks are slow" which makes people skeptical that a persistent structure can offer competitive performance. In fact disks are both much slower and much faster than people expect depending on how they are used; and a properly designed disk structure can often be as fast as the network.
+
+The key fact about disk performance is that the throughput of hard drives has been diverging from the latency of a disk seek for the last decade. As a result the performance of linear writes on a [JBOD](https://en.wikipedia.org/wiki/Non-RAID_drive_architectures) configuration with six 7200rpm SATA RAID-5 array is about 600MB/sec but the performance of random writes is only about 100kB/sec--a difference of over 6000X. These linear reads and writes are the most predictable of all usage pat [...]
+
+To compensate for this performance divergence, modern operating systems have become increasingly aggressive in their use of main memory for disk caching. A modern OS will happily divert _all_ free memory to disk caching with little performance penalty when the memory is reclaimed. All disk reads and writes will go through this unified cache. This feature cannot easily be turned off without using direct I/O, so even if a process maintains an in-process cache of the data, this data will li [...]
+
+Furthermore, we are building on top of the JVM, and anyone who has spent any time with Java memory usage knows two things:
+
+ 1. The memory overhead of objects is very high, often doubling the size of the data stored (or worse).
+ 2. Java garbage collection becomes increasingly fiddly and slow as the in-heap data increases.
+
+
+
+As a result of these factors using the filesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure--we at least double the available cache by having automatic access to all free memory, and likely double again by storing a compact byte structure rather than individual objects. Doing so will result in a cache of up to 28-30GB on a 32GB machine without GC penalties. Furthermore, this cache will stay warm even if the service is restarted, whereas the [...]
+
+This suggests a design which is very simple: rather than maintain as much as possible in-memory and flush it all out to the filesystem in a panic when we run out of space, we invert that. All data is immediately written to a persistent log on the filesystem without necessarily flushing to disk. In effect this just means that it is transferred into the kernel's pagecache.
+
+This style of pagecache-centric design is described in an [article](https://varnish-cache.org/wiki/ArchitectNotes) on the design of Varnish here (along with a healthy dose of arrogance).
+
+### Constant Time Suffices
+
+The persistent data structure used in messaging systems are often a per-consumer queue with an associated BTree or other general-purpose random access data structures to maintain metadata about messages. BTrees are the most versatile data structure available, and make it possible to support a wide variety of transactional and non-transactional semantics in the messaging system. They do come with a fairly high cost, though: Btree operations are O(log N). Normally O(log N) is considered es [...]
+
+Intuitively a persistent queue could be built on simple reads and appends to files as is commonly the case with logging solutions. This structure has the advantage that all operations are O(1) and reads do not block writes or each other. This has obvious performance advantages since the performance is completely decoupled from the data size--one server can now take full advantage of a number of cheap, low-rotational speed 1+TB SATA drives. Though they have poor seek performance, these dr [...]
+
+Having access to virtually unlimited disk space without any performance penalty means that we can provide some features not usually found in a messaging system. For example, in Kafka, instead of attempting to delete messages as soon as they are consumed, we can retain messages for a relatively long period (say a week). This leads to a great deal of flexibility for consumers, as we will describe.
+
+## Efficiency
+
+We have put significant effort into efficiency. One of our primary use cases is handling web activity data, which is very high volume: each page view may generate dozens of writes. Furthermore, we assume each message published is read by at least one consumer (often many), hence we strive to make consumption as cheap as possible.
+
+We have also found, from experience building and running a number of similar systems, that efficiency is a key to effective multi-tenant operations. If the downstream infrastructure service can easily become a bottleneck due to a small bump in usage by the application, such small changes will often create problems. By being very fast we help ensure that the application will tip over under load before the infrastructure. This is particularly important when trying to run a centralized serv [...]
+
+We discussed disk efficiency in the previous section. Once poor disk access patterns have been eliminated, there are two common causes of inefficiency in this type of system: too many small I/O operations, and excessive byte copying.
+
+The small I/O problem happens both between the client and the server and in the server's own persistent operations.
+
+To avoid this, our protocol is built around a "message set" abstraction that naturally groups messages together. This allows network requests to group messages together and amortize the overhead of the network roundtrip rather than sending a single message at a time. The server in turn appends chunks of messages to its log in one go, and the consumer fetches large linear chunks at a time.
+
+This simple optimization produces orders of magnitude speed up. Batching leads to larger network packets, larger sequential disk operations, contiguous memory blocks, and so on, all of which allows Kafka to turn a bursty stream of random message writes into linear writes that flow to the consumers.
+
+The other inefficiency is in byte copying. At low message rates this is not an issue, but under load the impact is significant. To avoid this we employ a standardized binary message format that is shared by the producer, the broker, and the consumer (so data chunks can be transferred without modification between them).
+
+The message log maintained by the broker is itself just a directory of files, each populated by a sequence of message sets that have been written to disk in the same format used by the producer and consumer. Maintaining this common format allows optimization of the most important operation: network transfer of persistent log chunks. Modern Unix operating systems offer a highly optimized code path for transferring data out of pagecache to a socket; in Linux this is done with the [sendfile [...]
+
+To understand the impact of sendfile, it is important to understand the common data path for transfer of data from file to socket:
+
+ 1. The operating system reads data from the disk into pagecache in kernel space
+ 2. The application reads the data from kernel space into a user-space buffer
+ 3. The application writes the data back into kernel space into a socket buffer
+ 4. The operating system copies the data from the socket buffer to the NIC buffer where it is sent over the network
+
+
+
+This is clearly inefficient, there are four copies and two system calls. Using sendfile, this re-copying is avoided by allowing the OS to send the data from pagecache to the network directly. So in this optimized path, only the final copy to the NIC buffer is needed.
+
+We expect a common use case to be multiple consumers on a topic. Using the zero-copy optimization above, data is copied into pagecache exactly once and reused on each consumption instead of being stored in memory and copied out to user-space every time it is read. This allows messages to be consumed at a rate that approaches the limit of the network connection.
+
+This combination of pagecache and sendfile means that on a Kafka cluster where the consumers are mostly caught up you will see no read activity on the disks whatsoever as they will be serving data entirely from cache.
+
+TLS/SSL libraries operate at the user space (in-kernel `SSL_sendfile` is currently not supported by Kafka). Due to this restriction, `sendfile` is not used when SSL is enabled. For enabling SSL configuration, refer to `security.protocol` and `security.inter.broker.protocol`
+
+For more background on the sendfile and zero-copy support in Java, see this [article](https://developer.ibm.com/articles/j-zerocopy/).
+
+### End-to-end Batch Compression
+
+In some cases the bottleneck is actually not CPU or disk but network bandwidth. This is particularly true for a data pipeline that needs to send messages between data centers over a wide-area network. Of course, the user can always compress its messages one at a time without any support needed from Kafka, but this can lead to very poor compression ratios as much of the redundancy is due to repetition between messages of the same type (e.g. field names in JSON or user agents in web logs o [...]
+
+Kafka supports this with an efficient batching format. A batch of messages can be grouped together, compressed, and sent to the server in this form. The broker decompresses the batch in order to validate it. For example, it validates that the number of records in the batch is same as what batch header states. This batch of messages is then written to disk in compressed form. The batch will remain compressed in the log and it will also be transmitted to the consumer in compressed form. Th [...]
+
+Kafka supports GZIP, Snappy, LZ4 and ZStandard compression protocols. More details on compression can be found [here](https://cwiki.apache.org/confluence/x/S5qoAQ).
+
+## The Producer
+
+### Load balancing
+
+The producer sends data directly to the broker that is the leader for the partition without any intervening routing tier. To help the producer do this all Kafka nodes can answer a request for metadata about which servers are alive and where the leaders for the partitions of a topic are at any given time to allow the producer to appropriately direct its requests.
+
+The client controls which partition it publishes messages to. This can be done at random, implementing a kind of random load balancing, or it can be done by some semantic partitioning function. We expose the interface for semantic partitioning by allowing the user to specify a key to partition by and using this to hash to a partition (there is also an option to override the partition function if need be). For example if the key chosen was a user id then all data for a given user would be [...]
+
+### Asynchronous send
+
+Batching is one of the big drivers of efficiency, and to enable batching the Kafka producer will attempt to accumulate data in memory and to send out larger batches in a single request. The batching can be configured to accumulate no more than a fixed number of messages and to wait no longer than some fixed latency bound (say 64kB or 10 ms). This allows the accumulation of more bytes to send, and few larger I/O operations on the servers. This buffering is configurable and gives a mechani [...]
+
+Details on configuration and the api for the producer can be found elsewhere in the documentation.
+
+## The Consumer
+
+The Kafka consumer works by issuing "fetch" requests to the brokers leading the partitions it wants to consume. The consumer specifies its offset in the log with each request and receives back a chunk of log beginning from that position. The consumer thus has significant control over this position and can rewind it to re-consume data if need be.
+
+### Push vs. pull
+
+An initial question we considered is whether consumers should pull data from brokers or brokers should push data to the consumer. In this respect Kafka follows a more traditional design, shared by most messaging systems, where data is pushed to the broker from the producer and pulled from the broker by the consumer. Some logging-centric systems, such as [Scribe](https://github.com/facebook/scribe) and [Apache Flume](https://flume.apache.org/), follow a very different push-based path wher [...]
+
+Another advantage of a pull-based system is that it lends itself to aggressive batching of data sent to the consumer. A push-based system must choose to either send a request immediately or accumulate more data and then send it later without knowledge of whether the downstream consumer will be able to immediately process it. If tuned for low latency, this will result in sending a single message at a time only for the transfer to end up being buffered anyway, which is wasteful. A pull-bas [...]
+
+The deficiency of a naive pull-based system is that if the broker has no data the consumer may end up polling in a tight loop, effectively busy-waiting for data to arrive. To avoid this we have parameters in our pull request that allow the consumer request to block in a "long poll" waiting until data arrives (and optionally waiting until a given number of bytes is available to ensure large transfer sizes).
+
+You could imagine other possible designs which would be only pull, end-to-end. The producer would locally write to a local log, and brokers would pull from that with consumers pulling from them. A similar type of "store-and-forward" producer is often proposed. This is intriguing but we felt not very suitable for our target use cases which have thousands of producers. Our experience running persistent data systems at scale led us to feel that involving thousands of disks in the system acr [...]
+
+### Consumer Position
+
+Keeping track of _what_ has been consumed is, surprisingly, one of the key performance points of a messaging system.
+
+Most messaging systems keep metadata about what messages have been consumed on the broker. That is, as a message is handed out to a consumer, the broker either records that fact locally immediately or it may wait for acknowledgement from the consumer. This is a fairly intuitive choice, and indeed for a single machine server it is not clear where else this state could go. Since the data structures used for storage in many messaging systems scale poorly, this is also a pragmatic choice--si [...]
+
+What is perhaps not obvious is that getting the broker and consumer to come into agreement about what has been consumed is not a trivial problem. If the broker records a message as **consumed** immediately every time it is handed out over the network, then if the consumer fails to process the message (say because it crashes or the request times out or whatever) that message will be lost. To solve this problem, many messaging systems add an acknowledgement feature which means that message [...]
+
+Kafka handles this differently. Our topic is divided into a set of totally ordered partitions, each of which is consumed by exactly one consumer within each subscribing consumer group at any given time. This means that the position of a consumer in each partition is just a single integer, the offset of the next message to consume. This makes the state about what has been consumed very small, just one number for each partition. This state can be periodically checkpointed. This makes the e [...]
+
+There is a side benefit of this decision. A consumer can deliberately _rewind_ back to an old offset and re-consume data. This violates the common contract of a queue, but turns out to be an essential feature for many consumers. For example, if the consumer code has a bug and is discovered after some messages are consumed, the consumer can re-consume those messages once the bug is fixed.
+
+### Offline Data Load
+
+Scalable persistence allows for the possibility of consumers that only periodically consume such as batch data loads that periodically bulk-load data into an offline system such as Hadoop or a relational data warehouse.
+
+In the case of Hadoop we parallelize the data load by splitting the load over individual map tasks, one for each node/topic/partition combination, allowing full parallelism in the loading. Hadoop provides the task management, and tasks which fail can restart without danger of duplicate data--they simply restart from their original position.
+
+### Static Membership
+
+Static membership aims to improve the availability of stream applications, consumer groups and other applications built on top of the group rebalance protocol. The rebalance protocol relies on the group coordinator to allocate entity ids to group members. These generated ids are ephemeral and will change when members restart and rejoin. For consumer based apps, this "dynamic membership" can cause a large percentage of tasks re-assigned to different instances during administrative operati [...]
+
+If you want to use static membership,
+
+ * Upgrade both broker cluster and client apps to 2.3 or beyond, and also make sure the upgraded brokers are using `inter.broker.protocol.version` of 2.3 or beyond as well.
+ * Set the config `ConsumerConfig#GROUP_INSTANCE_ID_CONFIG` to a unique value for each consumer instance under one group.
+ * For Kafka Streams applications, it is sufficient to set a unique `ConsumerConfig#GROUP_INSTANCE_ID_CONFIG` per KafkaStreams instance, independent of the number of used threads for an instance.
+
+If your broker is on an older version than 2.3, but you choose to set `ConsumerConfig#GROUP_INSTANCE_ID_CONFIG` on the client side, the application will detect the broker version and then throws an UnsupportedException. If you accidentally configure duplicate ids for different instances, a fencing mechanism on broker side will inform your duplicate client to shutdown immediately by triggering a `org.apache.kafka.common.errors.FencedInstanceIdException`. For more details, see [KIP-345](ht [...]
+
+## Message Delivery Semantics
+
+Now that we understand a little about how producers and consumers work, let's discuss the semantic guarantees Kafka provides between producer and consumer. Clearly there are multiple possible message delivery guarantees that could be provided:
+
+ * _At most once_ --Messages may be lost but are never redelivered.
+ * _At least once_ --Messages are never lost but may be redelivered.
+ * _Exactly once_ --Each message is processed once and only once.
+
+It's worth noting that this breaks down into two problems: the durability guarantees for publishing a message and the guarantees when consuming a message.
+
+Many systems claim to provide "exactly-once" delivery semantics, but it is important to read the fine print, because sometimes these claims are misleading (i.e. they don't translate to the case where consumers or producers can fail, cases where there are multiple consumer processes, or cases where data written to disk can be lost).
+
+Kafka's semantics are straightforward. When publishing a message we have a notion of the message being "committed" to the log. A message is considered committed only when all replicas in the in-sync replicas (ISR) for that partition have applied it to their log. Once a published message is committed, it will not be lost as long as one broker that replicates the partition to which this message was written remains "alive". The definition of committed message and alive partition as well as [...]
+
+Prior to 0.11.0.0, if a producer failed to receive a response indicating that a message was committed, it had little choice but to resend the message. This provides at-least-once delivery semantics since the message may be written to the log again during resending if the original request had in fact succeeded. Since 0.11.0.0, the Kafka producer also supports an idempotent delivery option which guarantees that resending will not result in duplicate entries in the log. To achieve this, the [...]
+
+Not all use cases require such strong guarantees. For use cases which are latency-sensitive, we allow the producer to specify the durability level it desires. If the producer specifies that it wants to wait on the message being committed, this can take on the order of 10 ms. However the producer can also specify that it wants to perform the send completely asynchronously or that it wants to wait only until the leader (but not necessarily the followers) have the message.
+
+Now let's describe the semantics from the point of view of the consumer. All replicas have the exact same log with the same offsets. The consumer controls its position in this log. If the consumer never crashed it could just store this position in memory, but if the consumer fails and we want this topic partition to be taken over by another process, the new process will need to choose an appropriate position from which to start processing. Let's say the consumer reads some messages -- it [...]
+
+ 1. It can read the messages, then save its position in the log, and finally process the messages. In this case there is a possibility that the consumer process crashes after saving its position but before saving the output of its message processing. In this case the process that took over processing would start at the saved position even though a few messages prior to that position had not been processed. This corresponds to "at-most-once" semantics as in the case of a consumer failure [...]
+ 2. It can read the messages, process the messages, and finally save its position. In this case there is a possibility that the consumer process crashes after processing messages but before saving its position. In this case when the new process takes over the first few messages it receives will already have been processed. This corresponds to the "at-least-once" semantics in the case of consumer failure. In many cases messages have a primary key and so the updates are idempotent (receiv [...]
+
+
+So what about exactly-once semantics? When consuming from a Kafka topic and producing to another topic (as in a [Kafka Streams](https://kafka.apache.org/documentation/streams) application), we can leverage the new transactional producer capabilities in 0.11.0.0 that were mentioned above. The consumer's position is stored as a message in an internal topic, so we can write the offset to Kafka in the same transaction as the output topics receiving the processed data. If the transaction is a [...]
+
+When writing to an external system, the limitation is in the need to coordinate the consumer's position with what is actually stored as output. The classic way of achieving this would be to introduce a two-phase commit between the storage of the consumer position and the storage of the consumers output. This can be handled more simply and generally by letting the consumer store its offset in the same place as its output. This is better because many of the output systems a consumer might [...]
+
+As a result, Kafka supports exactly-once delivery in [Kafka Streams](https://kafka.apache.org/documentation/streams), and the transactional producer and the consumer using read-committed isolation level can be used generally to provide exactly-once delivery when reading, processing and writing data on Kafka topics. Exactly-once delivery for other destination systems generally requires cooperation with such systems, but Kafka provides the primitives which makes implementing this feasible [...]
+
+## Using Transactions
+
+As mentioned above, the simplest way to get exactly-once semantics from Kafka is to use [Kafka Streams](https://kafka.apache.org/documentation/streams). However, it is also possible to achieve the same transactional guarantees using the Kafka producer and consumer directly by using them in the same way as Kafka Streams does.
+
+Kafka transactions are a bit different from transactions in other messaging systems. In Kafka, the consumer and producer are separate, and it is only the producer which is transactional. It is however able to make transactional updates to the consumer's position (confusingly called the "committed offset"), and it is this which gives the overall exactly-once behavior.
+
+There are three key aspects to exactly-once processing using the producer and consumer, which match how Kafka Streams works.
+
+ 1. The consumer uses partition assignment to ensure that it is the only consumer in the consumer group currently processing each partition.
+ 2. The producer uses transactions so that all the records it produces, and any offsets it updates on behalf of the consumer, are performed atomically.
+ 3. In order to handle transactions properly in combination with rebalancing, it is advisable to use one producer instance for each consumer instance. More complicated and efficient schemes are possible, but at the cost of greater complexity.
+
+
+
+In addition, it is generally considered a good practice to use the read-committed isolation level if trying to achieve exactly-once processing. Strictly speaking, the consumer doesn't have to use read-committed isolation level, but if it does not, it will see records from aborted transactions and also open transactions which have not yet completed.
+
+The consumer configuration must include `isolation.level=read_committed` and `enable.auto.commit=false`. The producer configuration must set `transactional.id` to the name of the transactional ID to be used, which configures the producer for transactional delivery and also makes sure that a restarted application causes any in-flight transaction from the previous instance to abort. Only the producer has the `transactional.id` configuration.
+
+Here's an example of a [transactional message copier](https://github.com/apache/kafka/blob/trunk/tools/src/main/java/org/apache/kafka/tools/TransactionalMessageCopier.java) which uses these principles. It uses a `KafkaConsumer` to consume records from one topic and a `KafkaProducer` to produce records to another topic. It uses transactions to ensure that there is no duplication or loss of records as they are copied, provided that the `--use-group-metadata` option is set.
+
+It is important to handle exceptions and aborted transactions correctly. Any records written by the transactional producer will be marked as being part of the transactions, and then when the transaction commits or aborts, transaction marker records are written to indicate the outcome of the transaction. This is how the read-committed consumer does not see records from aborted transactions. However, in the event of a transaction abort, the application's state and in particular the current [...]
+
+The error handling for transactional producer has been standardized which ensures consistent behavior and clearer error handling patterns. The exception categories are now more precisely defined:
+
+ 1. **RetriableException** : Temporary exceptions that are retried automatically by the client. These are handled internally and don't bubble up to the application.
+ 2. **RefreshRetriableException** : Exceptions requiring metadata refresh before retry. These are handled internally by the client after refreshing metadata and don't bubble up to the application.
+ 3. **AbortableException** : Exceptions that require transaction abort and reprocessing. These bubble up to the application, which must handle them by aborting the transaction and resetting the consumer position.
+ 4. **ApplicationRecoverableException** : Exceptions that bubble up to the application and require application handling. The application must implement its own recovery strategy, which must include restarting the producer.
+ 5. **InvalidConfigurationException** : Configuration-related exceptions that bubble up to the application and require application handling. The producer doesn't need to restart, but the application may choose to restart it.
+ 6. **KafkaException** : General Kafka exceptions that don't fit into the above categories. These bubble up to the application for handling.
+
+
+
+Example template code for handling transaction exceptions link : [ Transaction Client Demo](https://github.com/apache/kafka/blob/trunk/examples/src/main/java/kafka/examples/TransactionalClientDemo.java)
+
+A simple policy for handling exceptions and aborted transactions is to discard and recreate the Kafka producer and consumer objects and start afresh. As part of recreating the consumer, the consumer group will rebalance and fetch the last committed offset, which has the effect of rewinding back to the state before the transaction aborted. Alternatively, a more sophisticated application (such as the transactional message copier) can choose not to use `KafkaConsumer.committed` to retrieve [...]
+
+## The Share Consumer
+
+Most consumption of data from Kafka is performed by consumers in consumer groups. The way that consumer groups assign partitions to members of the group gives a powerful combination of ordering and scalability. However, some traditional messaging workloads are not a good fit for consumer groups.
+
+Share groups are another type of group, existing alongside traditional consumer groups. They offer an alternative to consumer groups, particularly when applications require finer-grained sharing of partitions and records. Share groups enable consumers to cooperatively consume and process records from topics. The consumers in a share group are called share consumers, and they use a familiar but different programming interface.
+
+The fundamental differences between a share group and a consumer group are:
+
+ * The consumers in a share group cooperatively consume records, and partitions may be assigned to multiple consumers.
+ * The number of consumers in a share group can exceed the number of partitions in a topic.
+ * Records are acknowledged individually, though the system is optimized for batch processing to improve efficiency.
+ * Delivery attempts to consumers in a share group are counted, which enables automated handling of unprocessable records.
+
+
+
+All share consumers in the same share group subscribed to the same topic will cooperatively consume the records of that topic. If a topic is accessed by consumers in multiple share groups, each share group consumes from that topic independently of the others.
+
+Each share consumer can dynamically set its list of subscribed topics. In practice, all consumers in a share group typically subscribe to the same topic or topics.
+
+When a share consumer fetches records, it receives available records from any of the topic-partitions matching its subscriptions. Records are acquired for delivery to this share consumer with a time-limited acquisition lock. While a record is acquired, it is unavailable to other consumers in the same share group for the duration of the lock.
+
+By default, the lock duration is 30 seconds, but you can control it using the group configuration parameter `share.record.lock.duration.ms`. The lock is released automatically once its duration elapses, making the record available to another delivery attempt. A share consumer holding the lock can handle the record in the following ways:
+
+ * Acknowledge successful processing of the record.
+ * Release the record, making it available for another delivery attempt.
+ * Reject the record, indicating it's unprocessable and preventing further delivery attempts for that record.
+ * Renew the record, extending the delivery attempt because the record is still being processed.
+ * Do nothing, in which case the lock is automatically released when its duration elapses.
+
+
+
+The Kafka cluster limits the number of records for each topic-partition acquired by share consumers in each share group. Once this limit is reached, fetching operations will temporarily yield no further records until the number of acquired records decreases (as locks naturally time out). This limit is controlled by the broker configuration property `group.share.partition.max.record.locks`. By limiting the duration of the acquisition lock and automatically releasing the locks, the broker [...]
+
+## Replication
+
+Kafka replicates the log for each topic's partitions across a configurable number of servers (you can set this replication factor on a topic-by-topic basis). This allows automatic failover to these replicas when a server in the cluster fails so messages remain available in the presence of failures.
+
+Other messaging systems provide some replication-related features, but, in our (totally biased) opinion, this appears to be a tacked-on thing, not heavily used, and with large downsides: replicas are inactive, throughput is heavily impacted, it requires fiddly manual configuration, etc. Kafka is meant to be used with replication by default--in fact we implement un-replicated topics as replicated topics where the replication factor is one.
+
+The unit of replication is the topic partition. Under non-failure conditions, each partition in Kafka has a single leader and zero or more followers. The total number of replicas including the leader constitute the replication factor. All writes go to the leader of the partition, and reads can go to the leader or the followers of the partition. Typically, there are many more partitions than brokers and the leaders are evenly distributed among brokers. The logs on the followers are identi [...]
+
+Followers consume messages from the leader just as a normal Kafka consumer would and apply them to their own log. Having the followers pull from the leader has the nice property of allowing the follower to naturally batch together log entries they are applying to their log.
+
+As with most distributed systems, automatically handling failures requires a precise definition of what it means for a node to be "alive." In Kafka, a special node known as the "controller" is responsible for managing the registration of brokers in the cluster. Broker liveness has two conditions:
+
+ 1. Brokers must maintain an active session with the controller in order to receive regular metadata updates.
+ 2. Brokers acting as followers must replicate the writes from the leader and not fall "too far" behind.
+
+
+
+What is meant by an "active session" depends on the cluster configuration. For KRaft clusters, an active session is maintained by sending periodic heartbeats to the controller. If the controller fails to receive a heartbeat before the timeout configured by `broker.session.timeout.ms` expires, then the node is considered offline.
+
+We refer to nodes satisfying these two conditions as being "in sync" to avoid the vagueness of "alive" or "failed". The leader keeps track of the set of "in sync" replicas, which is known as the ISR. If either of these conditions fail to be satisfied, then the broker will be removed from the ISR. For example, if a follower dies, then the controller will notice the failure through the loss of its session, and will remove the broker from the ISR. On the other hand, if the follower lags too [...]
+
+In distributed systems terminology we only attempt to handle a "fail/recover" model of failures where nodes suddenly cease working and then later recover (perhaps without knowing that they have died). Kafka does not handle so-called "Byzantine" failures in which nodes produce arbitrary or malicious responses (perhaps due to bugs or foul play).
+
+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 producer uses. Note that topics have a setting for the minimum number of [...]
+
+ 1. The messages are replicated to all the in-sync replicas.
+ 2. The number of the in-sync replicas is no less than the `min.insync.replicas` setting.
+
+
+
+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.
+
+Kafka will remain available in the presence of node failures after a short fail-over period, but may not remain available in the presence of network partitions.
+
+### Replicated Logs: Quorums, ISRs, and State Machines (Oh my!)
+
+At its heart a Kafka partition is a replicated log. The replicated log is one of the most basic primitives in distributed data systems, and there are many approaches for implementing one. A replicated log can be used by other systems as a primitive for implementing other distributed systems in the [state-machine style](https://en.wikipedia.org/wiki/State_machine_replication).
+
+A replicated log models the process of coming into consensus on the order of a series of values (generally numbering the log entries 0, 1, 2, ...). There are many ways to implement this, but the simplest and fastest is with a leader who chooses the ordering of values provided to it. As long as the leader remains alive, all followers need to only copy the values and ordering the leader chooses.
+
+Of course if leaders didn't fail we wouldn't need followers! When the leader does die we need to choose a new leader from among the followers. But followers themselves may fall behind or crash so we must ensure we choose an up-to-date follower. The fundamental guarantee a log replication algorithm must provide is that if we tell the client a message is committed, and the leader fails, the new leader we elect must also have that message. This yields a tradeoff: if the leader waits for mor [...]
+
+If you choose the number of acknowledgements required and the number of logs that must be compared to elect a leader such that there is guaranteed to be an overlap, then this is called a Quorum.
+
+A common approach to this tradeoff is to use a majority vote for both the commit decision and the leader election. This is not what Kafka does, but let's explore it anyway to understand the tradeoffs. Let's say we have 2 _f_ +1 replicas. If _f_ +1 replicas must receive a message prior to a commit being declared by the leader, and if we elect a new leader by electing the follower with the most complete log from at least _f_ +1 replicas, then, with no more than _f_ failures, the leader is [...]
+
+This majority vote approach has a very nice property: the latency is dependent on only the fastest servers. That is, if the replication factor is three, the latency is determined by the faster follower not the slower one.
+
+There are a rich variety of algorithms in this family including ZooKeeper's [Zab](https://web.archive.org/web/20140602093727/https://www.stanford.edu/class/cs347/reading/zab.pdf), [Raft](https://www.usenix.org/system/files/conference/atc14/atc14-paper-ongaro.pdf), and [Viewstamped Replication](https://pmg.csail.mit.edu/papers/vr-revisited.pdf). The most similar academic publication we are aware of to Kafka's actual implementation is [PacificA](https://research.microsoft.com/apps/pubs/def [...]
+
+The downside of majority vote is that it doesn't take many failures to leave you with no electable leaders. To tolerate one failure requires three copies of the data, and to tolerate two failures requires five copies of the data. In our experience having only enough redundancy to tolerate a single failure is not enough for a practical system, but doing every write five times, with 5x the disk space requirements and 1/5th the throughput, is not very practical for large volume data problem [...]
+
+Kafka takes a slightly different approach to choosing its quorum set. Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. Only members of this set are eligible for election as leader. A write to a Kafka partition is not considered committed until _all_ in-sync replicas have received the write. This ISR set is persisted in the cluster metadata whenever it changes. Because of this, any replica in the ISR is eligible to be [...]
+
+For most use cases we hope to handle, we think this tradeoff is a reasonable one. In practice, to tolerate _f_ failures, both the majority vote and the ISR approach will wait for the same number of replicas to acknowledge before committing a message (e.g. to survive one failure a majority quorum needs three replicas and one acknowledgement and the ISR approach requires two replicas and one acknowledgement). The ability to commit without the slowest servers is an advantage of the majority [...]
+
+Another important design distinction is that Kafka does not require that crashed nodes recover with all their data intact. It is not uncommon for replication algorithms in this space to depend on the existence of "stable storage" that cannot be lost in any failure-recovery scenario without potential consistency violations. There are two primary problems with this assumption. First, disk errors are the most common problem we observe in real operation of persistent data systems and they of [...]
+
+### Unclean leader election: What if they all die?
+
+Note that Kafka's guarantee with respect to data loss is predicated on at least one replica remaining in sync. If all the nodes replicating a partition die, this guarantee no longer holds.
+
+However a practical system needs to do something reasonable when all the replicas die. If you are unlucky enough to have this occur, it is important to consider what will happen. There are two behaviors that could be implemented:
+
+ 1. Wait for a replica in the ISR to come back to life and choose this replica as the leader (hopefully it still has all its data).
+ 2. Choose the first replica (not necessarily in the ISR) that comes back to life as the leader.
+
+
+This is a simple tradeoff between availability and consistency. If we wait for replicas in the ISR, then we will remain unavailable as long as those replicas are down. If such replicas were destroyed or their data was lost, then we are permanently down. If, on the other hand, a non-in-sync replica comes back to life and we allow it to become leader, then its log becomes the source of truth even though it is not guaranteed to have every committed message. By default from version 0.11.0.0, [...]
+
+This dilemma is not specific to Kafka. It exists in any quorum-based scheme. For example in a majority voting scheme, if a majority of servers suffer a permanent failure, then you must either choose to lose 100% of your data or violate consistency by taking what remains on an existing server as your new source of truth.
+
+### Availability and Durability Guarantees
+
+When writing to Kafka, producers can choose whether they wait for the message to be acknowledged by 0,1 or all (-1) replicas. Note that "acknowledgement by all replicas" does not guarantee that the full set of assigned replicas have received the message. By default, when acks=all, acknowledgement happens as soon as all the current in-sync replicas have received the message. For example, if a topic is configured with only two replicas and one fails (i.e., only one in sync replica remains) [...]
+
+ 1. Disable unclean leader election - if all replicas become unavailable, then the partition will remain unavailable until the most recent leader becomes available again. This effectively prefers unavailability over the risk of message loss. See the previous section on Unclean Leader Election for clarification.
+ 2. Specify a minimum ISR size - the partition will only accept writes if the size of the ISR is above a certain minimum, in order to prevent the loss of messages that were written to just a single replica, which subsequently becomes unavailable. This setting only takes effect if the producer uses acks=all and guarantees that the message will be acknowledged by at least this many in-sync replicas. This setting offers a trade-off between consistency and availability. A higher setting for [...]
+
+
+
+### Replica Management
+
+The above discussion on replicated logs really covers only a single log, i.e. one topic partition. However a Kafka cluster will manage hundreds or thousands of these partitions. We attempt to balance partitions within a cluster in a round-robin fashion to avoid clustering all partitions for high-volume topics on a small number of nodes. Likewise we try to balance leadership so that each node is the leader for a proportional share of its partitions.
+
+It is also important to optimize the leadership election process as that is the critical window of unavailability. A naive implementation of leader election would end up running an election per partition for all partitions a node hosted when that node failed. As discussed above in the section on replication, Kafka clusters have a special role known as the "controller" which is responsible for managing the registration of brokers. If the controller detects the failure of a broker, it is r [...]
+
+## Log Compaction
+
+Log compaction ensures that Kafka will always retain at least the last known value for each message key within the log of data for a single topic partition. It addresses use cases and scenarios such as restoring state after application crashes or system failure, or reloading caches after application restarts during operational maintenance. Let's dive into these use cases in more detail and then describe how compaction works.
+
+So far we have described only the simpler approach to data retention where old log data is discarded after a fixed period of time or when the log reaches some predetermined size. This works well for temporal event data such as logging where each record stands alone. However an important class of data streams are the log of changes to keyed, mutable data (for example, the changes to a database table).
+
+Let's discuss a concrete example of such a stream. Say we have a topic containing user email addresses; every time a user updates their email address we send a message to this topic using their user id as the primary key. Now say we send the following messages over some time period for a user with id 123, each message corresponding to a change in email address (messages for other ids are omitted):
+
+
+ 123 => bill@microsoft.com
+ .
+ .
+ .
+ 123 => bill@gatesfoundation.org
+ .
+ .
+ .
+ 123 => bill@gmail.com
+
+Log compaction gives us a more granular retention mechanism so that we are guaranteed to retain at least the last update for each primary key (e.g. `bill@gmail.com`). By doing this we guarantee that the log contains a full snapshot of the final value for every key not just keys that changed recently. This means downstream consumers can restore their own state off this topic without us having to retain a complete log of all changes.
+
+Let's start by looking at a few use cases where this is useful, then we'll see how it can be used.
+
+ 1. _Database change subscription_. It is often necessary to have a data set in multiple data systems, and often one of these systems is a database of some kind (either a RDBMS or perhaps a new-fangled key-value store). For example you might have a database, a cache, a search cluster, and a Hadoop cluster. Each change to the database will need to be reflected in the cache, the search cluster, and eventually in Hadoop. In the case that one is only handling the real-time updates you only [...]
+ 2. _Event sourcing_. This is a style of application design which co-locates query processing with application design and uses a log of changes as the primary store for the application.
+ 3. _Journaling for high-availability_. A process that does local computation can be made fault-tolerant by logging out changes that it makes to its local state so another process can reload these changes and carry on if it should fail. A concrete example of this is handling counts, aggregations, and other "group by"-like processing in a stream query system. Samza, a real-time stream-processing framework, [uses this feature](https://samza.apache.org/learn/documentation/0.7.0/container/s [...]
+In each of these cases one needs primarily to handle the real-time feed of changes, but occasionally, when a machine crashes or data needs to be re-loaded or re-processed, one needs to do a full load. Log compaction allows feeding both of these use cases off the same backing topic. This style of usage of a log is described in more detail in [this blog post](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying).
+
+The general idea is quite simple. If we had infinite log retention, and we logged each change in the above cases, then we would have captured the state of the system at each time from when it first began. Using this complete log, we could restore to any point in time by replaying the first N records in the log. This hypothetical complete log is not very practical for systems that update a single record many times as the log will grow without bound even for a stable dataset. The simple lo [...]
+
+Log compaction is a mechanism to give finer-grained per-record retention, rather than the coarser-grained time-based retention. The idea is to selectively remove records where we have a more recent update with the same primary key. This way the log is guaranteed to have at least the last state for each key.
+
+This retention policy can be set per-topic, so a single cluster can have some topics where retention is enforced by size or time and other topics where retention is enforced by compaction.
+
+This functionality is inspired by one of LinkedIn's oldest and most successful pieces of infrastructure--a database changelog caching service called [Databus](https://github.com/linkedin/databus). Unlike most log-structured storage systems Kafka is built for subscription and organizes data for fast linear reads and writes. Unlike Databus, Kafka acts as a source-of-truth store so it is useful even in situations where the upstream data source would not otherwise be replayable.
+
+### Log Compaction Basics
+
+Here is a high-level picture that shows the logical structure of a Kafka log with the offset for each message.
+
+
+
+The head of the log is identical to a traditional Kafka log. It has dense, sequential offsets and retains all messages. Log compaction adds an option for handling the tail of the log. The picture above shows a log with a compacted tail. Note that the messages in the tail of the log retain the original offset assigned when they were first written--that never changes. Note also that all offsets remain valid positions in the log, even if the message with that offset has been compacted away; [...]
+
+Compaction also allows for deletes. A message with a key and a null payload will be treated as a delete from the log. Such a record is sometimes referred to as a _tombstone_. This delete marker will cause any prior message with that key to be removed (as would any new message with that key), but delete markers are special in that they will themselves be cleaned out of the log after a period of time to free up space. The point in time at which deletes are no longer retained is marked as t [...]
+
+The compaction is done in the background by periodically recopying log segments. Cleaning does not block reads and can be throttled to use no more than a configurable amount of I/O throughput to avoid impacting producers and consumers. The actual process of compacting a log segment looks something like this:
+
+
+
+### What guarantees does log compaction provide?
+
+Log compaction guarantees the following:
+
+ 1. Any consumer that stays caught-up to within the head of the log will see every message that is written; these messages will have sequential offsets. The topic's `min.compaction.lag.ms` can be used to guarantee the minimum length of time must pass after a message is written before it could be compacted, that is, it provides a lower bound on how long each message will remain in the (uncompacted) head. The topic's `max.compaction.lag.ms` can be used to guarantee the maximum delay betwe [...]
+ 2. Ordering of messages is always maintained. Compaction will never re-order messages, just remove some.
+ 3. The offset for a message never changes. It is the permanent identifier for a position in the log.
+ 4. Any consumer progressing from the start of the log will see at least the final state of all records in the order they were written. Additionally, all delete markers for deleted records will be seen, provided the consumer reaches the head of the log in a time period less than the topic's `delete.retention.ms` setting (the default is 24 hours). In other words: since the removal of delete markers happens concurrently with reads, it is possible for a consumer to miss delete markers if i [...]
+
+
+### Log Compaction Details
+
+Log compaction is handled by the log cleaner, a pool of background threads that recopy log segment files, removing records whose key appears in the head of the log. Each compactor thread works as follows:
+
+ 1. It chooses the log that has the highest ratio of log head to log tail
+ 2. It creates a succinct summary of the last offset for each key in the head of the log
+ 3. It recopies the log from beginning to end removing keys which have a later occurrence in the log. New, clean segments are swapped into the log immediately so the additional disk space required is just one additional log segment (not a full copy of the log).
+ 4. The summary of the log head is essentially just a space-compact hash table. It uses exactly 24 bytes per entry. As a result with 8GB of cleaner buffer one cleaner iteration can clean around 366GB of log head (assuming 1kB messages).
+
+
+### Configuring The Log Cleaner
+
+The log cleaner is enabled by default. This will start the pool of cleaner threads. To enable log cleaning on a particular topic, add the log-specific property
+
+
+ log.cleanup.policy=compact
+
+The `log.cleanup.policy` property is a broker configuration setting defined in the broker's `server.properties` file; it affects all of the topics in the cluster that do not have a configuration override in place as documented [here](/documentation.html#brokerconfigs). The log cleaner can be configured to retain a minimum amount of the uncompacted "head" of the log. This is enabled by setting the compaction time lag.
+
+
+ log.cleaner.min.compaction.lag.ms
+
+This can be used to prevent messages newer than a minimum message age from being subject to compaction. If not set, all log segments are eligible for compaction except for the last segment, i.e. the one currently being written to. The active segment will not be compacted even if all of its messages are older than the minimum compaction time lag. The log cleaner can be configured to ensure a maximum delay after which the uncompacted "head" of the log becomes eligible for log compaction.
+
+
+ log.cleaner.max.compaction.lag.ms
+
+This can be used to prevent log with low produce rate from remaining ineligible for compaction for an unbounded duration. If not set, logs that do not exceed min.cleanable.dirty.ratio are not compacted. Note that this compaction deadline is not a hard guarantee since it is still subjected to the availability of log cleaner threads and the actual compaction time. You will want to monitor the uncleanable-partitions-count, max-clean-time-secs and max-compaction-delay-secs metrics.
+
+Further cleaner configurations are described [here](/documentation.html#brokerconfigs).
+
+## Quotas
+
+Kafka cluster has the ability to enforce quotas on requests to control the broker resources used by clients. Two types of client quotas can be enforced by Kafka brokers for each group of clients sharing a quota:
+
+ 1. Network bandwidth quotas define byte-rate thresholds (since 0.9)
+ 2. Request rate quotas define CPU utilization thresholds as a percentage of network and I/O threads (since 0.11)
+
+
+
+### Why are quotas necessary?
+
+It is possible for producers and consumers to produce/consume very high volumes of data or generate requests at a very high rate and thus monopolize broker resources, cause network saturation and generally DOS other clients and the brokers themselves. Having quotas protects against these issues and is all the more important in large multi-tenant clusters where a small set of badly behaved clients can degrade user experience for the well behaved ones. In fact, when running Kafka as a serv [...]
+
+### Client groups
+
+The identity of Kafka clients is the user principal which represents an authenticated user in a secure cluster. In a cluster that supports unauthenticated clients, user principal is a grouping of unauthenticated users chosen by the broker using a configurable `PrincipalBuilder`. Client-id is a logical grouping of clients with a meaningful name chosen by the client application. The tuple (user, client-id) defines a secure logical group of clients that share both user principal and client-id.
+
+Quotas can be applied to (user, client-id), user or client-id groups. For a given connection, the most specific quota matching the connection is applied. All connections of a quota group share the quota configured for the group. For example, if (user="test-user", client-id="test-client") has a produce quota of 10MB/sec, this is shared across all producer instances of user "test-user" with the client-id "test-client".
+
+### Quota Configuration
+
+Quota configuration may be defined for (user, client-id), user and client-id groups. It is possible to override the default quota at any of the quota levels that needs a higher (or even lower) quota. The mechanism is similar to the per-topic log config overrides. User and (user, client-id) quota overrides are written to the metadata log. These overrides are read by all brokers and are effective immediately. This lets us change quotas without having to do a rolling restart of the entire c [...]
+
+The order of precedence for quota configuration is:
+
+ 1. matching user and client-id quotas
+ 2. matching user and default client-id quotas
+ 3. matching user quota
+ 4. default user and matching client-id quotas
+ 5. default user and default client-id quotas
+ 6. default user quota
+ 7. matching client-id quota
+ 8. default client-id quota
+
+
+
+### Network Bandwidth Quotas
+
+Network bandwidth quotas are defined as the byte rate threshold for each group of clients sharing a quota. By default, each unique client group receives a fixed quota in bytes/sec as configured by the cluster. This quota is defined on a per-broker basis. Each group of clients can publish/fetch a maximum of X bytes/sec per broker before clients are throttled.
+
+### Request Rate Quotas
+
+Request rate quotas are defined as the percentage of time a client can utilize on request handler I/O threads and network threads of each broker within a quota window. A quota of `n%` represents `n%` of one thread, so the quota is out of a total capacity of `((num.io.threads + num.network.threads) * 100)%`. Each group of clients may use a total percentage of upto `n%` across all I/O and network threads in a quota window before being throttled. Since the number of threads allocated for I/ [...]
+
+### Enforcement
+
+By default, each unique client group receives a fixed quota as configured by the cluster. This quota is defined on a per-broker basis. Each client can utilize this quota per broker before it gets throttled. We decided that defining these quotas per broker is much better than having a fixed cluster wide bandwidth per client because that would require a mechanism to share client quota usage among all the brokers. This can be harder to get right than the quota implementation itself!
+
+How does a broker react when it detects a quota violation? In our solution, the broker first computes the amount of delay needed to bring the violating client under its quota and returns a response with the delay immediately. In case of a fetch request, the response will not contain any data. Then, the broker mutes the channel to the client, not to process requests from the client anymore, until the delay is over. Upon receiving a response with a non-zero delay duration, the Kafka client [...]
+
+Byte-rate and thread utilization are measured over multiple small windows (e.g. 30 windows of 1 second each) in order to detect and correct quota violations quickly. Typically, having large measurement windows (for e.g. 10 windows of 30 seconds each) leads to large bursts of traffic followed by long delays which is not great in terms of user experience.
diff --git a/docs/design/protocol.md b/docs/design/protocol.md
new file mode 100644
index 00000000000..d2953990096
--- /dev/null
+++ b/docs/design/protocol.md
@@ -0,0 +1,217 @@
+---
+title: Protocol
+description:
+weight: 2
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+# Kafka protocol guide
+
+This document covers the wire protocol implemented in Kafka. It is meant to give a readable guide to the protocol that covers the available requests, their binary format, and the proper way to make use of them to implement a client. This document assumes you understand the basic design and terminology described [here](https://kafka.apache.org/documentation.html#design)
+
+
+
+## Preliminaries
+
+### Network
+
+Kafka uses a binary protocol over TCP. The protocol defines all APIs as request response message pairs. All messages are size delimited and are made up of the following primitive types.
+
+The client initiates a socket connection and then writes a sequence of request messages and reads back the corresponding response message. No handshake is required on connection or disconnection. TCP is happier if you maintain persistent connections used for many requests to amortize the cost of the TCP handshake, but beyond this penalty connecting is pretty cheap.
+
+The client will likely need to maintain a connection to multiple brokers, as data is partitioned and the clients will need to talk to the server that has their data. However it should not generally be necessary to maintain multiple connections to a single broker from a single client instance (i.e. connection pooling).
+
+The server guarantees that on a single TCP connection, requests will be processed in the order they are sent and responses will return in that order as well. The broker's request processing allows only a single in-flight request per connection in order to guarantee this ordering. Note that clients can (and ideally should) use non-blocking IO to implement request pipelining and achieve higher throughput. i.e., clients can send requests even while awaiting responses for preceding requests [...]
+
+The server has a configurable maximum limit on request size and any request that exceeds this limit will result in the socket being disconnected.
+
+### Partitioning and bootstrapping
+
+Kafka is a partitioned system so not all servers have the complete data set. Instead recall that topics are split into a pre-defined number of partitions, P, and each partition is replicated with some replication factor, N. Topic partitions themselves are just ordered "commit logs" numbered 0, 1, ..., P-1.
+
+All systems of this nature have the question of how a particular piece of data is assigned to a particular partition. Kafka clients directly control this assignment, the brokers themselves enforce no particular semantics of which messages should be published to a particular partition. Rather, to publish messages the client directly addresses messages to a particular partition, and when fetching messages, fetches from a particular partition. If two clients want to use the same partitionin [...]
+
+These requests to publish or fetch data must be sent to the broker that is currently acting as the leader for a given partition. This condition is enforced by the broker, so a request for a particular partition to the wrong broker will result in an the NotLeaderForPartition error code (described below).
+
+How can the client find out which topics exist, what partitions they have, and which brokers currently host those partitions so that it can direct its requests to the right hosts? This information is dynamic, so you can't just configure each client with some static mapping file. Instead all Kafka brokers can answer a metadata request that describes the current state of the cluster: what topics there are, which partitions those topics have, which broker is the leader for those partitions, [...]
+
+In other words, the client needs to somehow find one broker and that broker will tell the client about all the other brokers that exist and what partitions they host. This first broker may itself go down so the best practice for a client implementation is to take a list of two or three URLs to bootstrap from. The user can then choose to use a load balancer or just statically configure two or three of their Kafka hosts in the clients.
+
+The client does not need to keep polling to see if the cluster has changed; it can fetch metadata once when it is instantiated cache that metadata until it receives an error indicating that the metadata is out of date. This error can come in two forms: (1) a socket error indicating the client cannot communicate with a particular broker, (2) an error code in the response to a request indicating that this broker no longer hosts the partition for which data was requested.
+
+ 1. Cycle through a list of "bootstrap" Kafka URLs until we find one we can connect to. Fetch cluster metadata.
+ 2. Process fetch or produce requests, directing them to the appropriate broker based on the topic/partitions they send to or fetch from.
+ 3. If we get an appropriate error, refresh the metadata and try again.
+
+
+
+### Partitioning Strategies
+
+As mentioned above the assignment of messages to partitions is something the producing client controls. That said, how should this functionality be exposed to the end-user?
+
+Partitioning really serves two purposes in Kafka:
+
+ 1. It balances data and request load over brokers
+ 2. It serves as a way to divvy up processing among consumer processes while allowing local state and preserving order within the partition. We call this semantic partitioning.
+
+
+
+For a given use case you may care about only one of these or both.
+
+To accomplish simple load balancing a simple approach would be for the client to just round robin requests over all brokers. Another alternative, in an environment where there are many more producers than brokers, would be to have each client chose a single partition at random and publish to that. This later strategy will result in far fewer TCP connections.
+
+Semantic partitioning means using some key in the message to assign messages to partitions. For example if you were processing a click message stream you might want to partition the stream by the user id so that all data for a particular user would go to a single consumer. To accomplish this the client can take a key associated with the message and use some hash of this key to choose the partition to which to deliver the message.
+
+### Batching
+
+Our APIs encourage batching small things together for efficiency. We have found this is a very significant performance win. Both our API to send messages and our API to fetch messages always work with a sequence of messages not a single message to encourage this. A clever client can make use of this and support an "asynchronous" mode in which it batches together messages sent individually and sends them in larger clumps. We go even further with this and allow the batching across multiple [...]
+
+The client implementer can choose to ignore this and send everything one at a time if they like.
+
+### Compatibility
+
+Kafka has a "bidirectional" client compatibility policy. In other words, new clients can talk to old servers, and old clients can talk to new servers. This allows users to upgrade either clients or servers without experiencing any downtime.
+
+Since the Kafka protocol has changed over time, clients and servers need to agree on the schema of the message that they are sending over the wire. This is done through API versioning.
+
+Before each request is sent, the client sends the API key and the API version. These two 16-bit numbers, when taken together, uniquely identify the schema of the message to follow.
+
+The intention is that clients will support a range of API versions. When communicating with a particular broker, a given client should use the highest API version supported by both and indicate this version in their requests.
+
+The server will reject requests with a version it does not support, and will always respond to the client with exactly the protocol format it expects based on the version it included in its request. The intended upgrade path is that new features would first be rolled out on the server (with the older clients not making use of them) and then as newer clients are deployed these new features would gradually be taken advantage of. Note there is an exceptional case while retrieving supported [...]
+
+Note that [KIP-482 tagged fields](https://cwiki.apache.org/confluence/x/OhMyBw) can be added to a request without incrementing the version number. This offers an additional way of evolving the message schema without breaking compatibility. Tagged fields do not take up any space when the field is not set. Therefore, if a field is rarely used, it is more efficient to make it a tagged field than to put it in the mandatory schema. However, tagged fields are ignored by recipients that don't k [...]
+
+### Retrieving Supported API versions
+
+In order to work against multiple broker versions, clients need to know what versions of various APIs a broker supports. The broker exposes this information since 0.10.0.0 as described in [KIP-35](https://cwiki.apache.org/confluence/x/KK6nAw). Clients should use the supported API versions information to choose the highest API version supported by both client and broker. If no such version exists, an error should be reported to the user.
+
+The following sequence may be used by a client to obtain supported API versions from a broker.
+
+ 1. Client sends `ApiVersionsRequest` to a broker after connection has been established with the broker. If SSL is enabled, this happens after SSL connection has been established.
+ 2. On receiving `ApiVersionsRequest`, a broker returns its full list of supported ApiKeys and versions regardless of current authentication state (e.g., before SASL authentication on an SASL listener, do note that no Kafka protocol requests may take place on an SSL listener before the SSL handshake is finished). If this is considered to leak information about the broker version a workaround is to use SSL with client authentication which is performed at an earlier stage of the connectio [...]
+ 3. If multiple versions of an API are supported by broker and client, clients are recommended to use the latest version supported by the broker and itself.
+ 4. Deprecation of a protocol version is done by marking an API version as deprecated in the protocol documentation.
+ 5. Supported API versions obtained from a broker are only valid for the connection on which that information is obtained. In the event of disconnection, the client should obtain the information from the broker again, as the broker might have been upgraded/downgraded in the mean time.
+
+
+
+### SASL Authentication Sequence
+
+The following sequence is used for SASL authentication:
+
+ 1. Kafka `ApiVersionsRequest` may be sent by the client to obtain the version ranges of requests supported by the broker. This is optional.
+ 2. Kafka `SaslHandshakeRequest` containing the SASL mechanism for authentication is sent by the client. If the requested mechanism is not enabled in the server, the server responds with the list of supported mechanisms and closes the client connection. If the mechanism is enabled in the server, the server sends a successful response and continues with SASL authentication.
+ 3. The actual SASL authentication is now performed. If `SaslHandshakeRequest` version is v0, a series of SASL client and server tokens corresponding to the mechanism are sent as opaque packets without wrapping the messages with Kafka protocol headers. If `SaslHandshakeRequest` version is v1, the `SaslAuthenticate` request/response are used, where the actual SASL tokens are wrapped in the Kafka protocol. The error code in the final message from the broker will indicate if authentication [...]
+ 4. If authentication succeeds, subsequent packets are handled as Kafka API requests. Otherwise, the client connection is closed.
+
+
+
+For interoperability with 0.9.0.x clients, the first packet received by the server is handled as a SASL/GSSAPI client token if it is not a valid Kafka request. SASL/GSSAPI authentication is performed starting with this packet, skipping the first two steps above.
+
+## The Protocol
+
+### Protocol Primitive Types
+
+The protocol is built out of the following primitive types.
+
+{{< include-html file="/static/42/generated/protocol_types.html" >}}
+
+### Notes on reading the request format grammars
+
+The [BNF](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form)s below give an exact context free grammar for the request and response binary format. The BNF is intentionally not compact in order to give human-readable name. As always in a BNF a sequence of productions indicates concatenation. When there are multiple possible productions these are separated with '|' and may be enclosed in parenthesis for grouping. The top-level definition is always given first and subsequent sub-parts [...]
+
+### Common Request and Response Structure
+
+All requests and responses originate from the following grammar which will be incrementally describe through the rest of this document:
+
+
+ RequestOrResponse => Size (RequestMessage | ResponseMessage)
+ Size => int32
+
+<table>
+<tr>
+<th>
+
+Field
+</th>
+<th>
+
+Description
+</th></tr>
+<tr>
+<td>
+
+message_size
+</td>
+<td>
+
+The message_size field gives the size of the subsequent request or response message in bytes. The client can read requests by first reading this 4 byte size as an integer N, and then reading and parsing the subsequent N bytes of the request.
+</td></tr> </table>
+
+### Request and Response Headers
+
+Different request and response versions require different versions of the corresponding headers. These header versions are specified below together with API message descriptions.
+
+### Record Batch
+
+A description of the record batch format can be found [here](/documentation/#recordbatch).
+
+## Constants
+
+### Error Codes
+
+We use numeric codes to indicate what problem occurred on the server. These can be translated by the client into exceptions or whatever the appropriate error handling mechanism in the client language. Here is a table of the error codes currently in use:
+
+{{< include-html file="/static/42/generated/protocol_errors.html" >}}
+
+### Api Keys
+
+The following are the numeric codes that the stable ApiKey in the request can take for each of the below request types.
+
+{{< include-html file="/static/42/generated/protocol_api_keys.html" >}}
+
+## The Messages
+
+This section gives details on each of the individual API Messages, their usage, their binary format, and the meaning of their fields.
+
+The message consists of the header and body:
+
+
+ Message => RequestOrResponseHeader Body
+
+
+`RequestOrResponseHeader` is the versioned request or response header. `Body` is the message-specific body.
+
+{{< include-html file="/static/42/generated/protocol_messages.html" >}}
+
+## Some Common Philosophical Questions
+
+Some people have asked why we don't use HTTP. There are a number of reasons, the best is that client implementors can make use of some of the more advanced TCP features--the ability to multiplex requests, the ability to simultaneously poll many connections, etc. We have also found HTTP libraries in many languages to be surprisingly shabby.
+
+Others have asked if maybe we shouldn't support many different protocols. Prior experience with this was that it makes it very hard to add and test new features if they have to be ported across many protocol implementations. Our feeling is that most users don't really see multiple protocols as a feature, they just want a good reliable client in the language of their choice.
+
+Another question is why we don't adopt XMPP, STOMP, AMQP or an existing protocol. The answer to this varies by protocol, but in general the problem is that the protocol does determine large parts of the implementation and we couldn't do what we are doing if we didn't have control over the protocol. Our belief is that it is possible to do better than existing messaging systems have in providing a truly distributed messaging system, and to do this we need to build something that works diff [...]
+
+A final question is why we don't use a system like Protocol Buffers or Thrift to define our request messages. These packages excel at helping you to managing lots and lots of serialized messages. However we have only a few messages. Support across languages is somewhat spotty (depending on the package). Finally the mapping between binary log format and wire protocol is something we manage somewhat carefully and this would not be possible with these systems. Finally we prefer the style of [...]
diff --git a/docs/docker.html b/docs/docker.html
deleted file mode 100644
index ef747199e4b..00000000000
--- a/docs/docker.html
+++ /dev/null
@@ -1,58 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script>
- <!--#include virtual="js/templateData.js" -->
-</script>
-
-<script id="docker-template" type="text/x-handlebars-template">
- <h4 class="anchor-heading">JVM Based Apache Kafka Docker Image</h4>
-
- <p>
- <a href="https://www.docker.com/">Docker</a> is a popular container runtime. Docker images for the JVM based Apache Kafka can be found on <a href="https://hub.docker.com/r/apache/kafka">Docker Hub</a> and are available from version 3.7.0.
- </p>
-
- <p> Docker image can be pulled from Docker Hub using the following command: </p>
- <pre><code class="language-bash">$ docker pull apache/kafka:{{fullDotVersion}}</code></pre>
- <p> If you want to fetch the latest version of the Docker image use following command: </p>
- <pre><code class="language-bash">$ docker pull apache/kafka:latest</code></pre>
- <p> To start the Kafka container using this Docker image with default configs and on default port 9092: </p>
- <pre><code class="language-bash">$ docker run -p 9092:9092 apache/kafka:{{fullDotVersion}}</code></pre>
-
- <h4 class="anchor-heading">GraalVM Based Native Apache Kafka Docker Image</h4>
-
- <p>
- Docker images for the GraalVM Based Native Apache Kafka can be found on <a href="https://hub.docker.com/r/apache/kafka-native">Docker Hub</a> and are available from version 3.8.0.<br>
- NOTE: This image is experimental and intended for local development and testing purposes only; it is not recommended for production use.
- </p>
-
- <p> Docker image can be pulled from Docker Hub using the following command: </p>
- <pre><code class="language-bash">$ docker pull apache/kafka-native:{{fullDotVersion}}</code></pre>
- <p> If you want to fetch the latest version of the Docker image use following command: </p>
- <pre><code class="language-bash">$ docker pull apache/kafka-native:latest</code></pre>
- <p> To start the Kafka container using this Docker image with default configs and on default port 9092: </p>
- <pre><code class="language-bash">$ docker run -p 9092:9092 apache/kafka-native:{{fullDotVersion}}</code></pre>
-
-
- <h4 class="anchor-heading">Usage guide</h4>
-
- <p>
- Detailed instructions for using the Docker image are mentioned <a href="https://github.com/apache/kafka/blob/trunk/docker/examples/README.md">here</a>.
- </p>
-</script>
-
-<div class="p-docker"></div>
\ No newline at end of file
diff --git a/docs/documentation.html b/docs/documentation.html
deleted file mode 100644
index 934e8a30c59..00000000000
--- a/docs/documentation.html
+++ /dev/null
@@ -1,124 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script><!--#include virtual="js/templateData.js" --></script>
-
-<!--#include virtual="../includes/_header.htm" -->
-<!--#include virtual="../includes/_top.htm" -->
-
-
-<div class="content documentation documentation--current">
- <!--#include virtual="../includes/_nav.htm" -->
- <div class="toc-handle-container">
- <div class="toc-handle"><</div>
- </div>
- <div class="docs-nav">
- <!--#include virtual="toc.html" -->
- </div>
- <div class="right">
- <!--//#include virtual="../includes/_docs_banner.htm" -->
-
- <h1>Documentation</h1>
- <h3>Kafka 4.1 Documentation</h3>
- Prior releases: <a href="/07/documentation.html">0.7.x</a>,
- <a href="/08/documentation.html">0.8.0</a>,
- <a href="/081/documentation.html">0.8.1.X</a>,
- <a href="/082/documentation.html">0.8.2.X</a>,
- <a href="/090/documentation.html">0.9.0.X</a>,
- <a href="/0100/documentation.html">0.10.0.X</a>,
- <a href="/0101/documentation.html">0.10.1.X</a>,
- <a href="/0102/documentation.html">0.10.2.X</a>,
- <a href="/0110/documentation.html">0.11.0.X</a>,
- <a href="/10/documentation.html">1.0.X</a>,
- <a href="/11/documentation.html">1.1.X</a>,
- <a href="/20/documentation.html">2.0.X</a>,
- <a href="/21/documentation.html">2.1.X</a>,
- <a href="/22/documentation.html">2.2.X</a>,
- <a href="/23/documentation.html">2.3.X</a>,
- <a href="/24/documentation.html">2.4.X</a>,
- <a href="/25/documentation.html">2.5.X</a>,
- <a href="/26/documentation.html">2.6.X</a>,
- <a href="/27/documentation.html">2.7.X</a>,
- <a href="/28/documentation.html">2.8.X</a>,
- <a href="/30/documentation.html">3.0.X</a>,
- <a href="/31/documentation.html">3.1.X</a>,
- <a href="/32/documentation.html">3.2.X</a>,
- <a href="/33/documentation.html">3.3.X</a>,
- <a href="/34/documentation.html">3.4.X</a>,
- <a href="/35/documentation.html">3.5.X</a>,
- <a href="/36/documentation.html">3.6.X</a>,
- <a href="/37/documentation.html">3.7.X</a>,
- <a href="/38/documentation.html">3.8.X</a>,
- <a href="/39/documentation.html">3.9.X</a>,
- <a href="/40/documentation.html">4.0.X</a>.
-
- <h2 class="anchor-heading"><a id="gettingStarted" class="anchor-link"></a><a href="#gettingStarted">1. Getting Started</a></h2>
- <h3 class="anchor-heading"><a id="introduction" class="anchor-link"></a><a href="#introduction">1.1 Introduction</a></h3>
- <!--#include virtual="introduction.html" -->
- <h3 class="anchor-heading"><a id="uses" class="anchor-link"></a><a href="#uses">1.2 Use Cases</a></h3>
- <!--#include virtual="uses.html" -->
- <h3 class="anchor-heading"><a id="quickstart" class="anchor-link"></a><a href="#quickstart">1.3 Quick Start</a></h3>
- <!--#include virtual="quickstart.html" -->
- <h3 class="anchor-heading"><a id="ecosystem" class="anchor-link"></a><a href="#ecosystem">1.4 Ecosystem</a></h3>
- <!--#include virtual="ecosystem.html" -->
- <h3 class="anchor-heading"><a id="upgrade" class="anchor-link"></a><a href="#upgrade">1.5 Upgrading From Previous Versions</a></h3>
- <!--#include virtual="upgrade.html" -->
- <h3 class="anchor-heading"><a id="zk2kraft-summary" class="anchor-link"></a><a href="#zk2kraft-summary">1.6 KRaft vs ZooKeeper</a></h3>
- <!--#include virtual="zk2kraft-summary.html" -->
- <h3 class="anchor-heading"><a id="compatibility-summary" class="anchor-link"></a><a href="#compatibility-summary">1.7 Compatibility</a></h3>
- <!--#include virtual="compatibility-summary.html" -->
- <h3 class="anchor-heading"><a id="docker" class="anchor-link"></a><a href="#docker">1.8 Docker</a></h3>
- <!--#include virtual="docker.html" -->
-
- <h2 class="anchor-heading"><a id="api" class="anchor-link"></a><a href="#api">2. APIs</a></h2>
-
- <!--#include virtual="api.html" -->
-
- <h2 class="anchor-heading"><a id="configuration" class="anchor-link"></a><a href="#configuration">3. Configuration</a></h2>
-
- <!--#include virtual="configuration.html" -->
-
- <h2 class="anchor-heading"><a id="design" class="anchor-link"></a><a href="#design">4. Design</a></h2>
-
- <!--#include virtual="design.html" -->
-
- <h2 class="anchor-heading"><a id="implementation" class="anchor-link"></a><a href="#implementation">5. Implementation</a></h2>
-
- <!--#include virtual="implementation.html" -->
-
- <h2 class="anchor-heading"><a id="operations" class="anchor-link"></a><a href="#operations">6. Operations</a></h2>
-
- <!--#include virtual="ops.html" -->
-
- <h2 class="anchor-heading"><a id="security" class="anchor-link"></a><a href="#security">7. Security</a></h2>
- <!--#include virtual="security.html" -->
-
- <h2 class="anchor-heading"><a id="connect" class="anchor-link"></a><a href="#connect">8. Kafka Connect</a></h2>
- <!--#include virtual="connect.html" -->
-
- <h2><a id="streams" href="#streams">9. Kafka Streams</a></h2>
- <p>
- Kafka Streams is a client library for processing and analyzing data stored in Kafka. It builds upon important stream processing concepts such as properly distinguishing between event time and processing time, windowing support, exactly-once processing semantics and simple yet efficient management of application state.
- </p>
- <p>
- Kafka Streams has a <b>low barrier to entry</b>: You can quickly write and run a small-scale proof-of-concept on a single machine; and you only need to run additional instances of your application on multiple machines to scale up to high-volume production workloads. Kafka Streams transparently handles the load balancing of multiple instances of the same application by leveraging Kafka's parallelism model.
- </p>
-
- <p>To learn more about Kafka Streams, visit the <a href="/documentation/streams">Kafka Streams page</a>.</p>
-
-<!--#include virtual="../includes/_footer.htm" -->
-<!--#include virtual="../includes/_docs_footer.htm" -->
diff --git a/docs/documentation/index.html b/docs/documentation/_index.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/_index.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/_index.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/compatibility.html b/docs/documentation/compatibility.html
deleted file mode 100644
index e1b5134ea40..00000000000
--- a/docs/documentation/compatibility.html
+++ /dev/null
@@ -1,201 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!--#include virtual="../../includes/_header.htm" -->
-<!--#include virtual="../../includes/_top.htm" -->
-<div class="content">
- <div class="p-compatibility">
- <h1>Compatibility</h1>
- With the release of Kafka 4.0, significant changes have been introduced that impact compatibility across various
- components. To assist users in planning upgrades and ensuring seamless interoperability, a comprehensive
- compatibility matrix has been prepared.
- <h2 class="anchor-heading">JDK Compatibility Across Kafka Versions</h2>
- <table>
- <tr>
- <th>Module</th>
- <th>Kafka Version</th>
- <th>Java 11</th>
- <th>Java 17</th>
- <th>Java 23</th>
- </tr>
- <tr>
- <td>Clients</td>
- <td>4.0.0</td>
- <td>✅</td>
- <td>✅</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>Streams</td>
- <td>4.0.0</td>
- <td>✅</td>
- <td>✅</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>Connect</td>
- <td>4.0.0</td>
- <td>❌</td>
- <td>✅</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>Server</td>
- <td>4.0.0</td>
- <td>❌</td>
- <td>✅</td>
- <td>✅</td>
- </tr>
- </table>
- <p><strong>Note: Java 8 is removed in Kafka 4.0 and is no longer supported.</strong></p>
-
- <h2 class="anchor-heading">Server Compatibility</h2>
- <table>
- <tr>
- <th>KRaft Cluster Version</th>
- <th>Compatibility 4.0 Server (dynamic voter)</th>
- <th>Compatibility 4.0 Server (static voter)</th>
- </tr>
- <tr>
- <td>before 3.2.x</td>
- <td>❌</td>
- <td>❌</td>
- </tr>
- <tr>
- <td>3.3.x</td>
- <td>❌</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>3.4.x</td>
- <td>❌</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>3.5.x</td>
- <td>❌</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>3.6.x</td>
- <td>❌</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>3.7.x</td>
- <td>❌</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>3.8.x</td>
- <td>❌</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>3.9.x</td>
- <td>✅</td>
- <td>✅</td>
- </tr>
- <tr>
- <td>4.0.x</td>
- <td>✅</td>
- <td>✅</td>
- </tr>
- </table>
- <p><strong>Note: Can’t upgrade server from static voter to dynamic
- voter, see <a href="https://issues.apache.org/jira/browse/KAFKA-16538">KAFKA-16538</a>.</strong></p>
-
- <h4>Client/Broker Forward Compatibility</h4>
- <table>
- <tr>
- <th>Kafka Version</th>
- <th>Module</th>
- <th>Compatibility with Kafka 4.0</th>
- <th>Key Differences/Limitations</th>
- </tr>
- <tr>
- <td rowspan="3">0.x, 1.x, 2.0</td>
- <td>Client</td>
- <td>❌ Not Compatible</td>
- <td>Pre-0.10.x protocols are fully removed in Kafka 4.0 (<a
- href="https://cwiki.apache.org/confluence/x/K5sODg">KIP-896</a>).
- </td>
- </tr>
- <tr>
- <td>Streams</td>
- <td>❌ Not Compatible</td>
- <td>Pre-0.10.x protocols are fully removed in Kafka 4.0 (<a
- href="https://cwiki.apache.org/confluence/x/K5sODg">KIP-896</a>).
- </td>
- </tr>
- <tr>
- <td>Connect</td>
- <td>❌ Not Compatible</td>
- <td>Pre-0.10.x protocols are fully removed in Kafka 4.0 (<a
- href="https://cwiki.apache.org/confluence/x/K5sODg">KIP-896</a>).
- </td>
- </tr>
- <tr>
- <td rowspan="3">2.1 ~ 2.8</td>
- <td>Client</td>
- <td>⚠️ Partially Compatible</td>
- <td>
- More details in the <a href="/40/documentation.html#upgrade_400_notable_consumer">Consumer</a>,
- <a href="/40/documentation.html#upgrade_400_notable_producer">Producer</a>, and
- <a href="/40/documentation.html#upgrade_400_notable_admin_client">Admin Client</a> section.
- </td>
- </tr>
- <tr>
- <td>Streams</td>
- <td>⚠️ Limited Compatibility</td>
- <td>
- More details in the <a href="/40/documentation.html#upgrade_400_notable_kafka_streams">Kafka Streams</a> section.
- </td>
- </tr>
- <tr>
- <td>Connect</td>
- <td>⚠️ Limited Compatibility</td>
- <td>
- More details in the <a href="/40/documentation.html#upgrade_400_notable_connect">Connect</a> section.
- </td>
- </tr>
- <tr>
- <td rowspan="3">3.x</td>
- <td>Client</td>
- <td>✅ Fully Compatible</td>
- <td></td>
- </tr>
- <tr>
- <td>Streams</td>
- <td>✅ Fully Compatible</td>
- <td></td>
- </tr>
- <tr>
- <td>Connect</td>
- <td>✅ Fully Compatible</td>
- <td></td>
- </tr>
- </table>
- <p>
- Note: Starting with Kafka 4.0, the <code>--zookeeper</code> option in AdminClient commands has been removed. Users must
- use the <code>--bootstrap-server</code> option to interact with the Kafka cluster. This change aligns with the transition
- to KRaft mode.
- </p>
-
- </div>
- <!--#include virtual="../../includes/_footer.htm" -->
-</div>
\ No newline at end of file
diff --git a/docs/documentation/streams/developer-guide/datatypes.html b/docs/documentation/legacy-redirect.md
similarity index 84%
rename from docs/documentation/streams/developer-guide/datatypes.html
rename to docs/documentation/legacy-redirect.md
index 98dd3a1c73a..8f1c32b575e 100644
--- a/docs/documentation/streams/developer-guide/datatypes.html
+++ b/docs/documentation/legacy-redirect.md
@@ -1,3 +1,11 @@
+---
+title: "Documentation Redirect Legacy"
+url: "/42/documentation.html"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,5 +23,5 @@
limitations under the License.
-->
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/datatypes.html" -->
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/tutorial.html b/docs/documentation/streams/_index.md
similarity index 86%
rename from docs/documentation/streams/tutorial.html
rename to docs/documentation/streams/_index.md
index e2cf4016e70..2e7bfb5ce4b 100644
--- a/docs/documentation/streams/tutorial.html
+++ b/docs/documentation/streams/_index.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,5 +22,5 @@
limitations under the License.
-->
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../streams/tutorial.html" -->
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/quickstart.html b/docs/documentation/streams/architecture.md
similarity index 86%
rename from docs/documentation/streams/quickstart.html
rename to docs/documentation/streams/architecture.md
index efb0234e240..2e7bfb5ce4b 100644
--- a/docs/documentation/streams/quickstart.html
+++ b/docs/documentation/streams/architecture.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,5 +22,5 @@
limitations under the License.
-->
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../streams/quickstart.html" -->
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/core-concepts.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/core-concepts.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/core-concepts.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/_index.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/_index.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/_index.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/app-reset-tool.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/app-reset-tool.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/app-reset-tool.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/config-streams.html b/docs/documentation/streams/developer-guide/config-streams.html
deleted file mode 100644
index 979f66d68a1..00000000000
--- a/docs/documentation/streams/developer-guide/config-streams.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/config-streams.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/config-streams.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/config-streams.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/config-streams.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/datatypes.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/datatypes.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/datatypes.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/dsl-api.html b/docs/documentation/streams/developer-guide/dsl-api.html
deleted file mode 100644
index 1bbc06d5d94..00000000000
--- a/docs/documentation/streams/developer-guide/dsl-api.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/dsl-api.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/dsl-api.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/dsl-api.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/dsl-api.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/dsl-topology-naming.html b/docs/documentation/streams/developer-guide/dsl-topology-naming.html
deleted file mode 100644
index 9f42a04ac0e..00000000000
--- a/docs/documentation/streams/developer-guide/dsl-topology-naming.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/dsl-topology-naming.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/dsl-topology-naming.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/dsl-topology-naming.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/dsl-topology-naming.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/index.html b/docs/documentation/streams/developer-guide/index.html
deleted file mode 100644
index 3a612477663..00000000000
--- a/docs/documentation/streams/developer-guide/index.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/index.html" -->
diff --git a/docs/documentation/streams/developer-guide/interactive-queries.html b/docs/documentation/streams/developer-guide/interactive-queries.html
deleted file mode 100644
index 05060121ebe..00000000000
--- a/docs/documentation/streams/developer-guide/interactive-queries.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/interactive-queries.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/interactive-queries.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/interactive-queries.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/interactive-queries.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/kafka-streams-group-sh.html b/docs/documentation/streams/developer-guide/kafka-streams-group-sh.html
deleted file mode 100644
index e9f8ef73da0..00000000000
--- a/docs/documentation/streams/developer-guide/kafka-streams-group-sh.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/kafka-streams-group-sh.html" -->
diff --git a/docs/documentation/streams/developer-guide/manage-topics.html b/docs/documentation/streams/developer-guide/manage-topics.html
deleted file mode 100644
index f4225541e39..00000000000
--- a/docs/documentation/streams/developer-guide/manage-topics.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/manage-topics.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/manage-topics.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/manage-topics.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/manage-topics.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/memory-mgmt.html b/docs/documentation/streams/developer-guide/memory-mgmt.html
deleted file mode 100644
index 024e1374cef..00000000000
--- a/docs/documentation/streams/developer-guide/memory-mgmt.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/memory-mgmt.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/memory-mgmt.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/memory-mgmt.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/memory-mgmt.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/processor-api.html b/docs/documentation/streams/developer-guide/processor-api.html
deleted file mode 100644
index 9e9ab91f019..00000000000
--- a/docs/documentation/streams/developer-guide/processor-api.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/processor-api.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/processor-api.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/processor-api.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/processor-api.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/running-app.html b/docs/documentation/streams/developer-guide/running-app.html
deleted file mode 100644
index 05d5f0b1f06..00000000000
--- a/docs/documentation/streams/developer-guide/running-app.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/running-app.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/running-app.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/running-app.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/running-app.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/security.html b/docs/documentation/streams/developer-guide/security.html
deleted file mode 100644
index 5d6e5f0d97e..00000000000
--- a/docs/documentation/streams/developer-guide/security.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/security.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/security.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/security.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/security.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/testing.html b/docs/documentation/streams/developer-guide/testing.html
deleted file mode 100644
index 4753e66ad1c..00000000000
--- a/docs/documentation/streams/developer-guide/testing.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/testing.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/testing.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/testing.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/testing.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/developer-guide/write-streams-app.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/developer-guide/write-streams-app.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/developer-guide/write-streams-app.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/developer-guide/write-streams.html b/docs/documentation/streams/developer-guide/write-streams.html
deleted file mode 100644
index 976c6fe1405..00000000000
--- a/docs/documentation/streams/developer-guide/write-streams.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../../streams/developer-guide/write-streams.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/introduction.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/introduction.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/introduction.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/quickstart.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/quickstart.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/quickstart.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/index.html b/docs/documentation/streams/tutorial.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/tutorial.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/tutorial.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/streams/upgrade-guide.html b/docs/documentation/streams/upgrade-guide.html
deleted file mode 100644
index b1b32007e51..00000000000
--- a/docs/documentation/streams/upgrade-guide.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../streams/upgrade-guide.html" -->
diff --git a/docs/documentation/index.html b/docs/documentation/streams/upgrade-guide.md
similarity index 88%
copy from docs/documentation/index.html
copy to docs/documentation/streams/upgrade-guide.md
index 1d7507f30a9..2e7bfb5ce4b 100644
--- a/docs/documentation/index.html
+++ b/docs/documentation/streams/upgrade-guide.md
@@ -1,3 +1,10 @@
+---
+title: "Documentation Redirect"
+robots: "noindex"
+_build:
+ list: false
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +22,5 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
+{{< doc-redirect >}}
diff --git a/docs/documentation/zk2kraft.html b/docs/documentation/zk2kraft.html
deleted file mode 100644
index 69e322bb048..00000000000
--- a/docs/documentation/zk2kraft.html
+++ /dev/null
@@ -1,320 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!--#include virtual="../../includes/_header.htm" -->
-<!--#include virtual="../../includes/_top.htm" -->
-<div class="content">
-<div class="p-zk2kraft">
- <h1>Differences Between KRaft mode and ZooKeeper mode</h1>
- <h2 class="anchor-heading">Removed ZooKeeper Features</h2>
- <p>
- This section documents differences in behavior between KRaft mode and ZooKeeper mode.
- Specifically, several configurations, metrics and features have changed or are no longer required in KRaft mode.
- To migrate an existing cluster from ZooKeeper mode to KRaft mode, please refer to the
- <a href="/39/documentation.html#kraft_zk_migration">ZooKeeper to KRaft Migration</a> section.
- </p>
- <h3 class="anchor-heading">Configurations</h3>
- <ul>
- <li>
- <p>
- Removed password encoder-related configurations. These configurations were used in
- ZooKeeper mode to define the key and backup key for encrypting sensitive data (e.g., passwords),
- specify the algorithm and key generation method for password encryption (e.g., AES, RSA), and control
- the key length and encryption strength.
- </p>
- <ul>
- <li><code>password.encoder.secret</code></li>
- <li><code>password.encoder.old.secret</code></li>
- <li><code>password.encoder.keyfactory.algorithm</code></li>
- <li><code>password.encoder.cipher.algorithm</code></li>
- <li><code>password.encoder.key.length</code></li>
- <li><code>password.encoder.iterations</code></li>
- </ul>
- <p>
- In KRaft mode, Kafka stores sensitive data in records, and the data is not encrypted in Kafka.
- </p>
- </li>
- <li>
- <p>
- Removed <code>control.plane.listener.name</code>. Kafka relies on ZooKeeper to manage metadata, but some
- internal operations (e.g., communication between controllers (a.k.a., broker controller) and brokers)
- still require Kafka’s internal control plane for coordination.
- </p>
- <p>
- In KRaft mode, Kafka eliminates its dependency on ZooKeeper, and the control plane functionality is
- fully integrated into Kafka itself. The process roles are clearly separated: brokers handle data-related
- requests, while the controllers (a.k.a., quorum controller) manages metadata-related requests. The controllers
- use the Raft protocol for internal communication, which operates differently from the ZooKeeper model. Use the
- following parameters to configure the control plane listener:
- </p>
- <ul>
- <li><code>controller.listener.names</code></li>
- <li><code>listeners</code></li>
- <li><code>listener.security.protocol.map</code></li>
- </ul>
- </li>
- <li>
- <p>
- Removed graceful broker shutdowns-related configurations. These configurations were used in ZooKeeper mode
- to define the maximum number of retries and the retry backoff time for controlled shutdowns. It can
- reduce the risk of unplanned leader changes and data inconsistencies.
- </p>
- <ul>
- <li><code>controlled.shutdown.max.retries</code></li>
- <li><code>controlled.shutdown.retry.backoff.ms</code></li>
- </ul>
- <p>
- In KRaft mode, Kafka uses the Raft protocol to manage metadata. The broker shutdown process differs from
- ZooKeeper mode as it is managed by the quorum-based controller. The shutdown process is more reliable
- and efficient due to automated leader transfers and metadata updates handled by the controller.
- </p>
- </li>
- <li>
- <p>
- Removed the broker id generation-related configurations. These configurations were used in ZooKeeper mode
- to specify the broker id auto generation and control the broker id generation process.
- </p>
- <ul>
- <li><code>reserved.broker.max.id</code></li>
- <li><code>broker.id.generation.enable</code></li>
- </ul>
- <p>
- Kafka uses the node id in KRaft mode to identify servers.
- </p>
- <ul>
- <li><code>node.id</code></li>
- </ul>
- </li>
- <li>
- <p>
- Removed broker protocol version-related configurations. These configurations were used in ZooKeeper mode to define communication protocol version between brokers.
- In KRaft mode, Kafka uses <code>metadata.version</code> to control the feature level of the cluster, which can be managed using <code>bin/kafka-features.sh</code>.
- </p>
- <ul>
- <li><code>inter.broker.protocol.version</code></li>
- </ul>
- </li>
- <li>
- <p>
- Removed dynamic configurations which relied on ZooKeeper. In KRaft mode, to change these configurations,
- you need to restart the broker/controller.
- </p>
- <ul>
- <li><code>advertised.listeners</code></li>
- </ul>
- </li>
- <li>
- <p>
- Removed the leader imbalance configuration used only in ZooKeeper. <code>leader.imbalance.per.broker.percentage</code>
- was used to limit the preferred leader election frequency in ZooKeeper.
- </p>
- <ul>
- <li><code>leader.imbalance.per.broker.percentage</code></li>
- </ul>
- </li>
- <li>
- <p>
- Removed ZooKeeper related configurations.
- </p>
- <ul>
- <li><code>zookeeper.connect</code></li>
- <li><code>zookeeper.session.timeout.ms</code></li>
- <li><code>zookeeper.connection.timeout.ms</code></li>
- <li><code>zookeeper.set.acl</code></li>
- <li><code>zookeeper.max.in.flight.requests</code></li>
- <li><code>zookeeper.ssl.client.enable</code></li>
- <li><code>zookeeper.clientCnxnSocket</code></li>
- <li><code>zookeeper.ssl.keystore.location</code></li>
- <li><code>zookeeper.ssl.keystore.password</code></li>
- <li><code>zookeeper.ssl.keystore.type</code></li>
- <li><code>zookeeper.ssl.truststore.location</code></li>
- <li><code>zookeeper.ssl.truststore.password</code></li>
- <li><code>zookeeper.ssl.truststore.type</code></li>
- <li><code>zookeeper.ssl.protocol</code></li>
- <li><code>zookeeper.ssl.enabled.protocols</code></li>
- <li><code>zookeeper.ssl.cipher.suites</code></li>
- <li><code>zookeeper.ssl.endpoint.identification.algorithm</code></li>
- <li><code>zookeeper.ssl.crl.enable</code></li>
- <li><code>zookeeper.ssl.ocsp.enable</code></li>
- </ul>
- </li>
- </ul>
- <h3 class="anchor-heading">Dynamic Log Levels</h3>
- <ul>
- <li>
- <p>
- The dynamic log levels feature allows you to change the log4j settings of a running broker or controller process without restarting it. The command-line syntax for setting dynamic log levels on brokers has not changed in KRaft mode. Here is an example of setting the log level on a broker:<br/>
- <pre><code class="language-bash">
-./bin/kafka-configs.sh --bootstrap-server localhost:9092 \
- --entity-type broker-loggers \
- --entity-name 1 \
- --alter \
- --add-config org.apache.kafka.raft.KafkaNetworkChannel=TRACE
- </code></pre>
- </p>
- </li>
- <li>
- <p>
- When setting dynamic log levels on the controllers, the <code>--bootstrap-controller</code> flag must be used. Here is an example of setting the log level ona controller:<br/>
- <pre><code class="language-bash">
-./bin/kafka-configs.sh --bootstrap-controller localhost:9093 \
- --entity-type broker-loggers \
- --entity-name 1 \
- --alter \
- --add-config org.apache.kafka.raft.KafkaNetworkChannel=TRACE
- </code></pre><br/>
- Note that the entity-type must be specified as <code>broker-loggers</code>, even though we are changing a controller's log level rather than a broker's log level.
- </p>
- </li>
- <li>
- <p>
- When changing the log level of a combined node, which has both broker and controller roles, either --bootstrap-servers or --bootstrap-controllers may be used. Combined nodes have only a single set of log levels; there are not different log levels for the broker and controller parts of the process.
- </p>
- </li>
- </ul>
- <h3 class="anchor-heading">Dynamic Controller Configurations</h3>
- <ul>
- <li>
- <p>
- Some Kafka configurations can be changed dynamically, without restarting the process. The command-line syntax for setting dynamic log levels on brokers has not changed in KRaft mode. Here is an example of setting the number of IO threads on a broker:<br/>
- <pre><code class="language-bash">
-./bin/kafka-configs.sh --bootstrap-server localhost:9092 \
- --entity-type brokers \
- --entity-name 1 \
- --alter \
- --add-config num.io.threads=5
- </code></pre>
- </p>
- </li>
- <li>
- <p>
- Controllers will apply all applicable cluster-level dynamic configurations. For example, the following command-line will change the <code>max.connections</code> setting on all of the brokers and all of the controllers in the cluster:<br/>
- <pre><code class="language-bash">
-./bin/kafka-configs.sh --bootstrap-server localhost:9092 \
- --entity-type brokers \
- --entity-default \
- --alter \
- --add-config max.connections=10000
- </code></pre><br/>
- It is not currently possible to apply a dynamic configuration on only a single controller.
- </p>
- </li>
- </ul>
- <h2 class="anchor-heading">Metrics</h2>
- <ul>
- <li>
- <p>
- Removed the following metrics related to ZooKeeper.
- <code>ControlPlaneNetworkProcessorAvgIdlePercent</code>
- is to monitor the average fraction of time the network processors are idle. The other <code>ControlPlaneExpiredConnectionsKilledCount</code>
- is to monitor the total number of connections disconnected, across all processors.
- </p>
- <ul>
- <li><code>ControlPlaneNetworkProcessorAvgIdlePercent</code></li>
- <li><code>ControlPlaneExpiredConnectionsKilledCount</code></li>
- </ul>
- <p>
- In KRaft mode, Kafka also provides metrics to monitor the network processors and expired connections.
- Use the following metrics to monitor the network processors and expired connections:
- </p>
- <ul>
- <li><code>NetworkProcessorAvgIdlePercent</code></li>
- <li><code>ExpiredConnectionsKilledCount</code></li>
- </ul>
- </li>
- <li>
- <p>
- Removed the metrics which are only used in ZooKeeper mode.
- </p>
- <ul>
- <li><code>kafka.controller:type=ControllerChannelManager,name=QueueSize</code></li>
- <li><code>kafka.controller:type=ControllerChannelManager,name=RequestRateAndQueueTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerEventManager,name=EventQueueSize</code></li>
- <li><code>kafka.controller:type=ControllerEventManager,name=EventQueueTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=AutoLeaderBalanceRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=ControlledShutdownRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=ControllerChangeRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=ControllerShutdownRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=IdleRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=IsrChangeRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=LeaderAndIsrResponseReceivedRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=ListPartitionReassignmentRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=LogDirChangeRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=ManualLeaderBalanceRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=KafkaController,name=MigratingZkBrokerCount</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=PartitionReassignmentRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=TopicChangeRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=TopicDeletionRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=KafkaController,name=TopicsIneligibleToDeleteCount</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=TopicUncleanLeaderElectionEnableRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=UncleanLeaderElectionEnableRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=UncleanLeaderElectionsPerSec</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=UpdateFeaturesRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=ControllerStats,name=UpdateMetadataResponseReceivedRateAndTimeMs</code></li>
- <li><code>kafka.controller:type=KafkaController,name=ActiveBrokerCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=ActiveControllerCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=ControllerState</code></li>
- <li><code>kafka.controller:type=KafkaController,name=FencedBrokerCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=GlobalPartitionCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=GlobalTopicCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=OfflinePartitionsCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=PreferredReplicaImbalanceCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=ReplicasIneligibleToDeleteCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=ReplicasToDeleteCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=TopicsToDeleteCount</code></li>
- <li><code>kafka.controller:type=KafkaController,name=ZkMigrationState</code></li>
- <li><code>kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=ElectLeader</code></li>
- <li><code>kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=topic</code></li>
- <li><code>kafka.server:type=DelayedOperationPurgatory,name=NumDelayedOperations,delayedOperation=ElectLeader</code></li>
- <li><code>kafka.server:type=DelayedOperationPurgatory,name=NumDelayedOperations,delayedOperation=topic</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=SessionState</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=ZooKeeperAuthFailuresPerSec</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=ZooKeeperDisconnectsPerSec</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=ZooKeeperExpiresPerSec</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=ZooKeeperReadOnlyConnectsPerSec</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=ZooKeeperSaslAuthenticationsPerSec</code></li>
- <li><code>kafka.server:type=SessionExpireListener,name=ZooKeeperSyncConnectsPerSec</code></li>
- <li><code>kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs</code></li>
- </ul>
- </li>
- </ul>
- <h2 class="anchor-heading">Behavioral Change Reference</h2>
- <p>
- This document catalogs the functional and operational differences between ZooKeeper mode and KRaft mode.
- </p>
- <ul>
- <li>
- <strong>Configuration Value Size Limitation</strong>: KRaft mode restricts configuration values to a maximum size of <code>Short.MAX_VALUE</code>,
- which prevents using the append operation to create larger configuration values.
- </li>
- <li>
- <strong>Policy Class Deployment</strong>:
- In KRaft mode, the <code>CreateTopicPolicy</code> and <code>AlterConfigPolicy</code> plugins run on the controller instead of the broker.
- This requires users to deploy the policy class JAR files on the controller and configure the parameters
- (<code>create.topic.policy.class.name</code> and <code>alter.config.policy.class.name</code>) on the controller.
- <p>Note: If migrating from ZooKeeper mode, ensure policy JARs are moved from brokers to controllers.</p>
- </li>
- <li>
- <strong>Custom implementations of <code>KafkaPrincipalBuilder</code></strong>:
- In KRaft mode, custom implementations of <code>KafkaPrincipalBuilder</code> must also implement <code>KafkaPrincipalSerde</code>; otherwise brokers will not be able to
- forward requests to the controller.
- </li>
- </ul>
-</div>
-<!--#include virtual="../../includes/_footer.htm" -->
-</div>
diff --git a/docs/documentation/index.html b/docs/getting-started/_index.md
similarity index 76%
copy from docs/documentation/index.html
copy to docs/getting-started/_index.md
index 1d7507f30a9..ad017db0dd8 100644
--- a/docs/documentation/index.html
+++ b/docs/getting-started/_index.md
@@ -1,3 +1,13 @@
+---
+title: Getting Started
+description: This section provides an overview of what Kafka is, why it is useful, and how to get started using it.
+weight: 1
+tags: ['kafka', 'docs', 'getting-started']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,4 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
diff --git a/docs/getting-started/compatibility.md b/docs/getting-started/compatibility.md
new file mode 100644
index 00000000000..098c912cf17
--- /dev/null
+++ b/docs/getting-started/compatibility.md
@@ -0,0 +1,428 @@
+---
+title: Compatibility
+description:
+weight: 7
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+With the release of Kafka 4.0, significant changes have been introduced that impact compatibility across various components. To assist users in planning upgrades and ensuring seamless interoperability, a comprehensive compatibility matrix has been prepared.
+
+# JDK Compatibility Across Kafka Versions
+
+<table>
+<tr>
+<th>
+
+Module
+</th>
+<th>
+
+Kafka Version
+</th>
+<th>
+
+Java 11
+</th>
+<th>
+
+Java 17
+</th>
+<th>
+
+Java 23
+</th> </tr>
+<tr>
+<td>
+
+Clients
+</td>
+<td>
+
+4.0.0
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+Streams
+</td>
+<td>
+
+4.0.0
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+Connect
+</td>
+<td>
+
+4.0.0
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+Server
+</td>
+<td>
+
+4.0.0
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td> </tr> </table>
+
+**Note: Java 8 is removed in Kafka 4.0 and is no longer supported.**
+
+# Server Compatibility
+
+<table>
+<tr>
+<th>
+
+KRaft Cluster Version
+</th>
+<th>
+
+Compatibility 4.0 Server (dynamic voter)
+</th>
+<th>
+
+Compatibility 4.0 Server (static voter)
+</th> </tr>
+<tr>
+<td>
+
+before 3.2.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+❌
+</td> </tr>
+<tr>
+<td>
+
+3.3.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+3.4.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+3.5.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+3.6.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+3.7.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+3.8.x
+</td>
+<td>
+
+❌
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+3.9.x
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td> </tr>
+<tr>
+<td>
+
+4.0.x
+</td>
+<td>
+
+✅
+</td>
+<td>
+
+✅
+</td> </tr> </table>
+
+**Note: Can’t upgrade server from static voter to dynamic voter, see[KAFKA-16538](https://issues.apache.org/jira/browse/KAFKA-16538).**
+
+## Client/Broker Forward Compatibility
+
+<table>
+<tr>
+<th>
+
+Kafka Version
+</th>
+<th>
+
+Module
+</th>
+<th>
+
+Compatibility with Kafka 4.0
+</th>
+<th>
+
+Key Differences/Limitations
+</th> </tr>
+<tr>
+<td>
+
+0.x, 1.x, 2.0
+</td>
+<td>
+
+Client
+</td>
+<td>
+
+❌ Not Compatible
+</td>
+<td>
+
+Pre-0.10.x protocols are fully removed in Kafka 4.0 ([KIP-896](https://cwiki.apache.org/confluence/x/K5sODg)).
+</td> </tr>
+<tr>
+<td>
+
+Streams
+</td>
+<td>
+
+❌ Not Compatible
+</td>
+<td>
+
+Pre-0.10.x protocols are fully removed in Kafka 4.0 ([KIP-896](https://cwiki.apache.org/confluence/x/K5sODg)).
+</td> </tr>
+<tr>
+<td>
+
+Connect
+</td>
+<td>
+
+❌ Not Compatible
+</td>
+<td>
+
+Pre-0.10.x protocols are fully removed in Kafka 4.0 ([KIP-896](https://cwiki.apache.org/confluence/x/K5sODg)).
+</td> </tr>
+<tr>
+<td>
+
+2.1 ~ 2.8
+</td>
+<td>
+
+Client
+</td>
+<td>
+
+⚠️ Partially Compatible
+</td>
+<td>
+
+More details in the [Consumer](/40/documentation.html#upgrade_400_notable_consumer), [Producer](/40/documentation.html#upgrade_400_notable_producer), and [Admin Client](/40/documentation.html#upgrade_400_notable_admin_client) section.
+</td> </tr>
+<tr>
+<td>
+
+Streams
+</td>
+<td>
+
+⚠️ Limited Compatibility
+</td>
+<td>
+
+More details in the [Kafka Streams](/40/documentation.html#upgrade_400_notable_kafka_streams) section.
+</td> </tr>
+<tr>
+<td>
+
+Connect
+</td>
+<td>
+
+⚠️ Limited Compatibility
+</td>
+<td>
+
+More details in the [Connect](/40/documentation.html#upgrade_400_notable_connect) section.
+</td> </tr>
+<tr>
+<td>
+
+3.x
+</td>
+<td>
+
+Client
+</td>
+<td>
+
+✅ Fully Compatible
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+Streams
+</td>
+<td>
+
+✅ Fully Compatible
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+Connect
+</td>
+<td>
+
+✅ Fully Compatible
+</td>
+<td>
+
+
+</td> </tr> </table>
+
+Note: Starting with Kafka 4.0, the `--zookeeper` option in AdminClient commands has been removed. Users must use the `--bootstrap-server` option to interact with the Kafka cluster. This change aligns with the transition to KRaft mode.
diff --git a/docs/getting-started/docker.md b/docs/getting-started/docker.md
new file mode 100644
index 00000000000..9fd766223bc
--- /dev/null
+++ b/docs/getting-started/docker.md
@@ -0,0 +1,70 @@
+---
+title: Docker
+description:
+weight: 8
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## JVM Based Apache Kafka Docker Image
+
+[Docker](https://www.docker.com/) is a popular container runtime. Docker images for the JVM based Apache Kafka can be found on [Docker Hub](https://hub.docker.com/r/apache/kafka) and are available from version 3.7.0.
+
+Docker image can be pulled from Docker Hub using the following command:
+
+
+ $ docker pull apache/kafka:4.2.0
+
+If you want to fetch the latest version of the Docker image use following command:
+
+
+ $ docker pull apache/kafka:latest
+
+To start the Kafka container using this Docker image with default configs and on default port 9092:
+
+
+ $ docker run -p 9092:9092 apache/kafka:4.2.0
+
+## GraalVM Based Native Apache Kafka Docker Image
+
+Docker images for the GraalVM Based Native Apache Kafka can be found on [Docker Hub](https://hub.docker.com/r/apache/kafka-native) and are available from version 3.8.0.
+NOTE: This image is experimental and intended for local development and testing purposes only; it is not recommended for production use.
+
+Docker image can be pulled from Docker Hub using the following command:
+
+
+ $ docker pull apache/kafka-native:4.2.0
+
+If you want to fetch the latest version of the Docker image use following command:
+
+
+ $ docker pull apache/kafka-native:latest
+
+To start the Kafka container using this Docker image with default configs and on default port 9092:
+
+
+ $ docker run -p 9092:9092 apache/kafka-native:4.2.0
+
+## Usage guide
+
+Detailed instructions for using the Docker image are mentioned [here](https://github.com/apache/kafka/blob/trunk/docker/examples/README.md).
diff --git a/docs/ecosystem.html b/docs/getting-started/ecosystem.md
similarity index 72%
rename from docs/ecosystem.html
rename to docs/getting-started/ecosystem.md
index a198e2efd71..39ce31ead7b 100644
--- a/docs/ecosystem.html
+++ b/docs/getting-started/ecosystem.md
@@ -1,3 +1,13 @@
+---
+title: Ecosystem
+description:
+weight: 4
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,5 @@
limitations under the License.
-->
-There are a plethora of tools that integrate with Kafka outside the main distribution. The <a href="https://cwiki.apache.org/confluence/x/Ri3VAQ"> ecosystem page</a> lists many of these, including stream processing systems, Hadoop integration, monitoring, and deployment tools.
+
+There are a plethora of tools that integrate with Kafka outside the main distribution. The [ ecosystem page](https://cwiki.apache.org/confluence/x/Ri3VAQ) lists many of these, including stream processing systems, Hadoop integration, monitoring, and deployment tools.
diff --git a/docs/getting-started/introduction.md b/docs/getting-started/introduction.md
new file mode 100644
index 00000000000..f8ebd50a4f3
--- /dev/null
+++ b/docs/getting-started/introduction.md
@@ -0,0 +1,110 @@
+---
+title: Introduction
+description:
+weight: 1
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## What is event streaming?
+
+Event streaming is the digital equivalent of the human body's central nervous system. It is the technological foundation for the 'always-on' world where businesses are increasingly software-defined and automated, and where the user of software is more software.
+
+Technically speaking, event streaming is the practice of capturing data in real-time from event sources like databases, sensors, mobile devices, cloud services, and software applications in the form of streams of events; storing these event streams durably for later retrieval; manipulating, processing, and reacting to the event streams in real-time as well as retrospectively; and routing the event streams to different destination technologies as needed. Event streaming thus ensures a con [...]
+
+## What can I use event streaming for?
+
+Event streaming is applied to a [wide variety of use cases](/powered-by) across a plethora of industries and organizations. Its many examples include:
+
+ * To process payments and financial transactions in real-time, such as in stock exchanges, banks, and insurances.
+ * To track and monitor cars, trucks, fleets, and shipments in real-time, such as in logistics and the automotive industry.
+ * To continuously capture and analyze sensor data from IoT devices or other equipment, such as in factories and wind parks.
+ * To collect and immediately react to customer interactions and orders, such as in retail, the hotel and travel industry, and mobile applications.
+ * To monitor patients in hospital care and predict changes in condition to ensure timely treatment in emergencies.
+ * To connect, store, and make available data produced by different divisions of a company.
+ * To serve as the foundation for data platforms, event-driven architectures, and microservices.
+
+
+
+## Apache Kafka® is an event streaming platform. What does that mean?
+
+Kafka combines three key capabilities so you can implement [your use cases](/powered-by) for event streaming end-to-end with a single battle-tested solution:
+
+ 1. To **publish** (write) and **subscribe to** (read) streams of events, including continuous import/export of your data from other systems.
+ 2. To **store** streams of events durably and reliably for as long as you want.
+ 3. To **process** streams of events as they occur or retrospectively.
+
+
+
+And all this functionality is provided in a distributed, highly scalable, elastic, fault-tolerant, and secure manner. Kafka can be deployed on bare-metal hardware, virtual machines, and containers, and on-premises as well as in the cloud. You can choose between self-managing your Kafka environments and using fully managed services offered by a variety of vendors.
+
+## How does Kafka work in a nutshell?
+
+Kafka is a distributed system consisting of **servers** and **clients** that communicate via a high-performance [TCP network protocol](/protocol.html). It can be deployed on bare-metal hardware, virtual machines, and containers in on-premise as well as cloud environments.
+
+**Servers** : Kafka is run as a cluster of one or more servers that can span multiple datacenters or cloud regions. Some of these servers form the storage layer, called the brokers. Other servers run [Kafka Connect](/documentation/#connect) to continuously import and export data as event streams to integrate Kafka with your existing systems such as relational databases as well as other Kafka clusters. To let you implement mission-critical use cases, a Kafka cluster is highly scalable and [...]
+
+**Clients** : They allow you to write distributed applications and microservices that read, write, and process streams of events in parallel, at scale, and in a fault-tolerant manner even in the case of network problems or machine failures. Kafka ships with some such clients included, which are augmented by [dozens of clients](https://cwiki.apache.org/confluence/x/3gDVAQ) provided by the Kafka community: clients are available for Java and Scala including the higher-level [Kafka Streams]( [...]
+
+## Main Concepts and Terminology
+
+An **event** records the fact that "something happened" in the world or in your business. It is also called record or message in the documentation. When you read or write data to Kafka, you do this in the form of events. Conceptually, an event has a key, value, timestamp, and optional metadata headers. Here's an example event:
+
+ * Event key: "Alice"
+ * Event value: "Made a payment of $200 to Bob"
+ * Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
+
+
+
+**Producers** are those client applications that publish (write) events to Kafka, and **consumers** are those that subscribe to (read and process) these events. In Kafka, producers and consumers are fully decoupled and agnostic of each other, which is a key design element to achieve the high scalability that Kafka is known for. For example, producers never need to wait for consumers. Kafka provides various [guarantees](/documentation/#semantics) such as the ability to process events exac [...]
+
+Events are organized and durably stored in **topics**. Very simplified, a topic is similar to a folder in a filesystem, and the events are the files in that folder. An example topic name could be "payments". Topics in Kafka are always multi-producer and multi-subscriber: a topic can have zero, one, or many producers that write events to it, as well as zero, one, or many consumers that subscribe to these events. Events in a topic can be read as often as needed—unlike traditional messaging [...]
+
+Topics are **partitioned** , meaning a topic is spread over a number of "buckets" located on different Kafka brokers. This distributed placement of your data is very important for scalability because it allows client applications to both read and write the data from/to many brokers at the same time. When a new event is published to a topic, it is actually appended to one of the topic's partitions. Events with the same event key (e.g., a customer or vehicle ID) are written to the same par [...]
+
+ Figure: This example topic has four partitions P1–P4. Two different producer clients are publishing, independently from each other, new events to the topic by writing events over the network to the topic's partitions. Events with the same key (denoted by their color in the figure) are written to the same partition. Note that both producers can write to the same partition if appropriate.
+
+To make your data fault-tolerant and highly-available, every topic can be **replicated** , even across geo-regions or datacenters, so that there are always multiple brokers that have a copy of the data just in case things go wrong, you want to do maintenance on the brokers, and so on. A common production setting is a replication factor of 3, i.e., there will always be three copies of your data. This replication is performed at the level of topic-partitions.
+
+This primer should be sufficient for an introduction. The [Design](/documentation/#design) section of the documentation explains Kafka's various concepts in full detail, if you are interested.
+
+## Kafka APIs
+
+In addition to command line tooling for management and administration tasks, Kafka has five core APIs for Java and Scala:
+
+ * The [Admin API](/documentation.html#adminapi) to manage and inspect topics, brokers, and other Kafka objects.
+ * The [Producer API](/documentation.html#producerapi) to publish (write) a stream of events to one or more Kafka topics.
+ * The [Consumer API](/documentation.html#consumerapi) to subscribe to (read) one or more topics and to process the stream of events produced to them.
+ * The [Kafka Streams API](/documentation/streams) to implement stream processing applications and microservices. It provides higher-level functions to process event streams, including transformations, stateful operations like aggregations and joins, windowing, processing based on event-time, and more. Input is read from one or more topics in order to generate output to one or more topics, effectively transforming the input streams to output streams.
+ * The [Kafka Connect API](/documentation.html#connect) to build and run reusable data import/export connectors that consume (read) or produce (write) streams of events from and to external systems and applications so they can integrate with Kafka. For example, a connector to a relational database like PostgreSQL might capture every change to a set of tables. However, in practice, you typically don't need to implement your own connectors because the Kafka community already provides hund [...]
+
+
+
+## Where to go from here
+
+ * To get hands-on experience with Kafka, follow the [Quickstart](/quickstart).
+ * To understand Kafka in more detail, read the [Documentation](/documentation/). You also have your choice of [Kafka books and academic papers](/books-and-papers).
+ * Browse through the [Use Cases](/powered-by) to learn how other users in our world-wide community are getting value out of Kafka.
+ * Join a [local Kafka meetup group](/events) and [watch talks from Kafka Summit](https://kafka-summit.org/past-events/), the main conference of the Kafka community.
+
+
diff --git a/docs/getting-started/quickstart.md b/docs/getting-started/quickstart.md
new file mode 100644
index 00000000000..853774401ea
--- /dev/null
+++ b/docs/getting-started/quickstart.md
@@ -0,0 +1,228 @@
+---
+title: Quick Start
+description:
+weight: 3
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## Step 1: Get Kafka
+
+[Download](https://www.apache.org/dyn/closer.cgi?path=/kafka/4.2.0/kafka_2.13-4.2.0.tgz) the latest Kafka release and extract it:
+
+
+ $ tar -xzf kafka_2.13-4.2.0.tgz
+ $ cd kafka_2.13-4.2.0
+
+## Step 2: Start the Kafka environment
+
+NOTE: Your local environment must have Java 17+ installed.
+
+Kafka can be run using local scripts and downloaded files or the docker image.
+
+### Using downloaded files
+
+Generate a Cluster UUID
+
+
+ $ KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
+
+Format Log Directories
+
+
+ $ bin/kafka-storage.sh format --standalone -t $KAFKA_CLUSTER_ID -c config/server.properties
+
+Start the Kafka Server
+
+
+ $ bin/kafka-server-start.sh config/server.properties
+
+Once the Kafka server has successfully launched, you will have a basic Kafka environment running and ready to use.
+
+### Using JVM Based Apache Kafka Docker Image
+
+Get the Docker image:
+
+
+ $ docker pull apache/kafka:4.2.0
+
+Start the Kafka Docker container:
+
+
+ $ docker run -p 9092:9092 apache/kafka:4.2.0
+
+### Using GraalVM Based Native Apache Kafka Docker Image
+
+Get the Docker image:
+
+
+ $ docker pull apache/kafka-native:4.2.0
+
+Start the Kafka Docker container:
+
+
+ $ docker run -p 9092:9092 apache/kafka-native:4.2.0
+
+## Step 3: Create a topic to store your events
+
+Kafka is a distributed _event streaming platform_ that lets you read, write, store, and process [_events_](/documentation/#messages) (also called _records_ or _messages_ in the documentation) across many machines.
+
+Example events are payment transactions, geolocation updates from mobile phones, shipping orders, sensor measurements from IoT devices or medical equipment, and much more. These events are organized and stored in [_topics_](/documentation/#intro_concepts_and_terms). Very simplified, a topic is similar to a folder in a filesystem, and the events are the files in that folder.
+
+So before you can write your first events, you must create a topic. Open another terminal session and run:
+
+
+ $ bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092
+
+All of Kafka's command line tools have additional options: run the `kafka-topics.sh` command without any arguments to display usage information. For example, it can also show you [details such as the partition count](/documentation/#intro_concepts_and_terms) of the new topic:
+
+
+ $ bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092
+ Topic: quickstart-events TopicId: NPmZHyhbR9y00wMglMH2sg PartitionCount: 1 ReplicationFactor: 1 Configs:
+ Topic: quickstart-events Partition: 0 Leader: 0 Replicas: 0 Isr: 0
+
+## Step 4: Write some events into the topic
+
+A Kafka client communicates with the Kafka brokers via the network for writing (or reading) events. Once received, the brokers will store the events in a durable and fault-tolerant manner for as long as you need—even forever.
+
+Run the console producer client to write a few events into your topic. By default, each line you enter will result in a separate event being written to the topic.
+
+
+ $ bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092
+ >This is my first event
+ >This is my second event
+
+You can stop the producer client with `Ctrl-C` at any time.
+
+## Step 5: Read the events
+
+Open another terminal session and run the console consumer client to read the events you just created:
+
+
+ $ bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092
+ This is my first event
+ This is my second event
+
+You can stop the consumer client with `Ctrl-C` at any time.
+
+Feel free to experiment: for example, switch back to your producer terminal (previous step) to write additional events, and see how the events immediately show up in your consumer terminal.
+
+Because events are durably stored in Kafka, they can be read as many times and by as many consumers as you want. You can easily verify this by opening yet another terminal session and re-running the previous command again.
+
+## Step 6: Import/export your data as streams of events with Kafka Connect
+
+You probably have lots of data in existing systems like relational databases or traditional messaging systems, along with many applications that already use these systems. [Kafka Connect](/documentation/#connect) allows you to continuously ingest data from external systems into Kafka, and vice versa. It is an extensible tool that runs _connectors_ , which implement the custom logic for interacting with an external system. It is thus very easy to integrate existing systems with Kafka. To [...]
+
+In this quickstart we'll see how to run Kafka Connect with simple connectors that import data from a file to a Kafka topic and export data from a Kafka topic to a file.
+
+First, make sure to add `connect-file-4.2.0.jar` to the `plugin.path` property in the Connect worker's configuration. For the purpose of this quickstart we'll use a relative path and consider the connectors' package as an uber jar, which works when the quickstart commands are run from the installation directory. However, it's worth noting that for production deployments using absolute paths is always preferable. See [plugin.path](/documentation/#connectconfigs_plugin.path) for a detailed [...]
+
+Edit the `config/connect-standalone.properties` file, add or change the `plugin.path` configuration property match the following, and save the file:
+
+
+ $ echo "plugin.path=libs/connect-file-4.2.0.jar" >> config/connect-standalone.properties
+
+Then, start by creating some seed data to test with:
+
+
+ $ echo -e "foo
+ bar" > test.txt
+
+Or on Windows:
+
+
+ $ echo foo > test.txt
+ $ echo bar >> test.txt
+
+Next, we'll start two connectors running in _standalone_ mode, which means they run in a single, local, dedicated process. We provide three configuration files as parameters. The first is always the configuration for the Kafka Connect process, containing common configuration such as the Kafka brokers to connect to and the serialization format for data. The remaining configuration files each specify a connector to create. These files include a unique connector name, the connector class to [...]
+
+
+ $ bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties
+
+These sample configuration files, included with Kafka, use the default local cluster configuration you started earlier and create two connectors: the first is a source connector that reads lines from an input file and produces each to a Kafka topic and the second is a sink connector that reads messages from a Kafka topic and produces each as a line in an output file.
+
+During startup you'll see a number of log messages, including some indicating that the connectors are being instantiated. Once the Kafka Connect process has started, the source connector should start reading lines from `test.txt` and producing them to the topic `connect-test`, and the sink connector should start reading messages from the topic `connect-test` and write them to the file `test.sink.txt`. We can verify the data has been delivered through the entire pipeline by examining the [...]
+
+
+ $ more test.sink.txt
+ foo
+ bar
+
+Note that the data is being stored in the Kafka topic `connect-test`, so we can also run a console consumer to see the data in the topic (or use custom consumer code to process it):
+
+
+ $ bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic connect-test --from-beginning
+ {"schema":{"type":"string","optional":false},"payload":"foo"}
+ {"schema":{"type":"string","optional":false},"payload":"bar"}
+ …
+
+The connectors continue to process data, so we can add data to the file and see it move through the pipeline:
+
+
+ $ echo "Another line" >> test.txt
+
+You should see the line appear in the console consumer output and in the sink file.
+
+## Step 7: Process your events with Kafka Streams
+
+Once your data is stored in Kafka as events, you can process the data with the [Kafka Streams](/documentation/streams) client library for Java/Scala. It allows you to implement mission-critical real-time applications and microservices, where the input and/or output data is stored in Kafka topics. Kafka Streams combines the simplicity of writing and deploying standard Java and Scala applications on the client side with the benefits of Kafka's server-side cluster technology to make these a [...]
+
+To give you a first taste, here's how one would implement the popular `WordCount` algorithm:
+
+
+ KStream<String, String> textLines = builder.stream("quickstart-events");
+
+ KTable<String, Long> wordCounts = textLines
+ .flatMapValues(line -> Arrays.asList(line.toLowerCase().split(" ")))
+ .groupBy((keyIgnored, word) -> word)
+ .count();
+
+ wordCounts.toStream().to("output-topic", Produced.with(Serdes.String(), Serdes.Long()));
+
+The [Kafka Streams demo](/documentation/streams/quickstart) and the [app development tutorial](/42/documentation/streams/tutorial) demonstrate how to code and run such a streaming application from start to finish.
+
+## Step 8: Terminate the Kafka environment
+
+Now that you reached the end of the quickstart, feel free to tear down the Kafka environment—or continue playing around.
+
+ 1. Stop the producer and consumer clients with `Ctrl-C`, if you haven't done so already.
+ 2. Stop the Kafka broker with `Ctrl-C`.
+
+
+
+If you also want to delete any data of your local Kafka environment including any events you have created along the way, run the command:
+
+
+ $ rm -rf /tmp/kafka-logs /tmp/kraft-combined-logs
+
+## Congratulations!
+
+You have successfully finished the Apache Kafka quickstart.
+
+To learn more, we suggest the following next steps:
+
+ * Read through the brief [Introduction](/intro) to learn how Kafka works at a high level, its main concepts, and how it compares to other technologies. To understand Kafka in more detail, head over to the [Documentation](/documentation/).
+ * Browse through the [Use Cases](/powered-by) to learn how other users in our world-wide community are getting value out of Kafka.
+ * Join a [local Kafka meetup group](/events) and [watch talks from Kafka Summit](https://kafka-summit.org/past-events/), the main conference of the Kafka community.
+
+
diff --git a/docs/getting-started/upgrade.md b/docs/getting-started/upgrade.md
new file mode 100644
index 00000000000..34d516d462b
--- /dev/null
+++ b/docs/getting-started/upgrade.md
@@ -0,0 +1,256 @@
+---
+title: Upgrading
+description:
+weight: 5
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## Upgrading to 4.2.0
+
+### Upgrading Servers to 4.2.0 from any version 3.3.x through 4.1.x
+
+### Notable changes in 4.2.0
+
+ * The `--max-partition-memory-bytes` option in `kafka-console-producer` is deprecated and will be removed in Kafka 5.0. Please use `--batch-size` instead.
+ * Queues for Kafka ([KIP-932](https://cwiki.apache.org/confluence/x/4hA0Dw)) is production-ready in Apache Kafka 4.2. This feature introduces a new kind of group called share groups, as an alternative to consumer groups. Consumers in a share group cooperatively consume records from topics, without assigning each partition to just one consumer. Share groups also introduce per-record acknowledgement and counting of delivery attempts. Use share groups in cases where records are processed [...]
+ * The `org.apache.kafka.common.header.internals.RecordHeader` class has been updated to be read thread-safe. See [KIP-1205](https://cwiki.apache.org/confluence/x/nYmhFg) for details. In other words, each individual `Header` object within a `ConsumerRecord`'s `headers` can now be safely read from multiple threads concurrently.
+ * The `org.apache.kafka.disallowed.login.modules` config was deprecated. Please use the `org.apache.kafka.allowed.login.modules` instead.
+ * The `remote.log.manager.thread.pool.size` config was deprecated. Please use the `remote.log.manager.follower.thread.pool.size` instead.
+ * The `KafkaPrincipalBuilder` now extends `KafkaPrincipalSerde`. Force developer to implement `KafkaPrincipalSerde` interface for custom `KafkaPrincipalBuilder`. For further details, please refer to [KIP-1157](https://cwiki.apache.org/confluence/x/1gq9F).
+ * The behavior of `org.apache.kafka.streams.KafkaStreams#removeStreamThread` has been changed. The consumer has no longer remove once `removeStreamThread` finished. Instead, consumer would be kicked off from the group after `org.apache.kafka.streams.processor.internals.StreamThread` completes its `run` function.
+ * The support for MX4J library, enabled through `kafka_mx4jenable` system property, was deprecated and will be removed in Kafka 5.0.
+ * The `PARTITIONER_ADPATIVE_PARTITIONING_ENABLE_CONFIG` in `ProducerConfig` was deprecated and will be removed in Kafka 5.0. Please use the `PARTITIONER_ADAPTIVE_PARTITIONING_ENABLE_CONFIG` instead.
+ * The `ConsumerPerformance` command line tool has a new `--include` option that is an alternative to the `--topic` option. This new option allows to pass a regular expression specifying a list of topics to include for consumption, which is useful to test consumer performance across multiple topics or dynamically matching topic sets.
+ * The consistency of argument names for the command-line tools has been improved ([KIP-1147](https://cwiki.apache.org/confluence/x/DguWF)). The deprecated options will be removed in Kafka 5.0.
+ * In `kafka-producer-perf-test.sh`, `--bootstrap-server` and `--reporting-interval` option are added.
+ * In `kafka-console-consumer.sh` and `kafka-console-share-consumer.sh`, the option `--property` which is used to specify the properties for the formatter is deprecated in favor of `--formatter-property`.
+ * In `kafka-console-producer.sh`, the option `--property` which is used to specify properties in the form key=value to the message reader is deprecated in favor of `--reader-property`.
+ * In `kafka-consumer-perf-test.sh` and `kafka-share-consumer-perf-test.sh`, the option `--messages` is deprecated in favor of `--num-records` to bring all performance testing tools in line.
+ * The option `--command-property` is used for all command-line tools which accept configuration properties directly on the command line. The tools affected are:
+ * `kafka-console-consumer.sh`, `kafka-console-producer.sh` and `kafka-console-share-consumer.sh` (`--consumer-property` and `--producer-property` are deprecated in favor of `--command-property`)
+ * `kafka-producer-perf-test.sh` (`--producer-props` is deprecated in favor of `--command-property`)
+ * `kafka-consumer-perf-test.sh` and `kafka-share-consumer-perf-test.sh` gain the `--command-property` option to bring all performance testing tools in line
+ * The option `--command-config` is used for all command-line tools which accept a file of configuration properties. The tools affected are:
+ * `kafka-cluster.sh` (`--config` is deprecated in favor of `--command-config`)
+ * `kafka-console-consumer.sh`, `kafka-console-producer.sh` and `kafka-console-share-consumer.sh` (`--consumer.config` and `--producer.config` are deprecated in favor of `--command-config`)
+ * `kafka-consumer-perf-test.sh`, `kafka-producer-perf-test.sh` and `kafka-share-consumer-perf-test.sh` (`--consumer.config` and `--producer.config` are deprecated in favor of `--command-config`)
+ * `kafka-verifiable-consumer.sh` and `kafka-verifiable-producer.sh` (`--consumer.config` and `--producer.config` are deprecated in favor of `--command-config`)
+ * `kafka-leader-election.sh` (`--admin.config` is deprecated in favor of `--command-config`)
+ * `kafka-streams-application-reset.sh` (`--config-file` is deprecated in favor of `--command-config`)
+ * The `num.replica.fetchers` config has a new lower bound of 1.
+ * Improvements have been made to the validation rules and default values of LIST-type configurations ([KIP-1161](https://cwiki.apache.org/confluence/x/HArXF)).
+ * LIST-type configurations now enforce stricter validation:
+ * Null values are no longer accepted for most LIST-type configurations. Exceptions apply only to configurations that have null as their default value, as users cannot explicitly assign null values in configuration files or through the API.
+ * Most LIST-type configurations no longer accept duplicate entries, except in cases where duplicates are explicitly supported. For backward compatibility, if users configure duplicate entries when they are not accepted, duplicate entries will be ignored and a warning will be logged.
+ * For certain configurations, an empty list causes the system to malfunction. Therefore, empty lists are no longer allowed for those configurations.
+ * Several configurations have been reclassified from STRING-type to LIST-type to better reflect their intended use as comma-separated values.
+ * Default values for certain configurations have been adjusted to ensure better consistency with related settings.
+ * `cleanup.policy` now supports empty values, which means infinite retention. This is equivalent to setting `retention.ms=-1` and `retention.bytes=-1`
+If `cleanup.policy` is empty and `remote.storage.enable` is set to true, the local log segments will be cleaned based on the values of `log.local.retention.bytes` and `log.local.retention.ms`.
+If `cleanup.policy` is empty and `remote.storage.enable` is set to false, local log segments will not be deleted automatically. However, records can still be deleted explicitly through `deleteRecords` API calls, which will advance the log start offset and remove the corresponding log segments.
+ * The `controller.quorum.auto.join.enable` has been added to `QuorumConfig`, enabling KRaft controllers to automatically join the cluster's voter set, and defaults to false. For further details, please refer to [KIP-853](https://cwiki.apache.org/confluence/x/nyH1D).
+ * The AppInfo metrics will deprecate the following metric names, which will be removed in Kafka 5.0:
+ * `[name=start-time-ms, group=app-info, description=Metric indicating start-time-ms, tags={}]`
+ * `[name=commit-id, group=app-info, description=Metric indicating commit-id, tags={}]`
+ * `[name=version, group=app-info, description=Metric indicating version, tags={}]`
+In addition, the `client-id` will be added to the tags of these metrics. The new metric names will be:
+ * `[name=start-time-ms, group=app-info, description=Metric indicating start-time-ms, tags={client-id=...}]`
+ * `[name=commit-id, group=app-info, description=Metric indicating commit-id, tags={client-id=...}]`
+ * `[name=version, group=app-info, description=Metric indicating version, tags={client-id=...}]`
+For further details, please refer to [KIP-1120](https://cwiki.apache.org/confluence/x/3gn0Ew).
+ * The metrics `org.apache.kafka.server:type=AssignmentsManager.QueuedReplicaToDirAssignments`, `org.apache.kafka.storage.internals.log:type=RemoteStorageThreadPool.RemoteLogReaderTaskQueueSize`, and `org.apache.kafka.storage.internals.log:type=RemoteStorageThreadPool.RemoteLogReaderAvgIdlePercent` have been deprecated and will be removed in Kafka 5.0. As replacements, the following metrics have been introduced, which report the same information: `kafka.server:type=AssignmentsManager.Qu [...]
+ * A new metric `AvgIdleRatio` has been added to the `ControllerEventManager` and `MetadataLoader` groups. These metrics measure the average idle ratio of their respective event queue threads, providing visibility into how much time each component spends waiting for events versus processing them. The metric value ranges from 0.0 (always busy) to 1.0 (always idle).
+ * Deprecated `org.apache.kafka.streams.KafkaStreams$CloseOptions` and its related methods, such as `KafkaStreams#close(org.apache.kafka.streams.KafkaStreams$CloseOptions)`. As a replacement, please use `org.apache.kafka.streams.CloseOptions` and `KafkaStreams#close(org.apache.kafka.streams.CloseOptions)`. For further details, please refer to [KIP-1153](https://cwiki.apache.org/confluence/x/QAq9F).
+ * A new implementation of `ConnectorClientConfigOverridePolicy`, `AllowlistConnectorClientConfigOverridePolicy`, has been added. This enables specifying the configurations that connectors can override via `connector.client.config.override.allowlist`. From Kafka 5.0.0, this will be the default [connector.client.config.override.policy](documentation/#connectconfigs_connector.client.config.override.policy) policy. The `PrincipalConnectorClientConfigOverridePolicy` policy is now deprecated [...]
+ * It is now possible to specify the start time for a Kafka Streams punctuation, instead of relying on the non-deterministic time when you register it. For further details, please refer to [KIP-1146](https://cwiki.apache.org/confluence/x/9QqWF).
+ * Added an optional `--node-id` flag to the `FeatureCommand` command. It specifies the node to describe. If not provided, an arbitrary node is used.
+
+
+
+## Upgrading to 4.1.0
+
+**Note:** Kafka Streams 4.1.0 contains a critical memory leak bug ([KAFKA-19748](https://issues.apache.org/jira/browse/KAFKA-19748)) that affects users of range scans and certain DSL operators (session windows, sliding windows, stream-stream joins, foreign-key joins). Users running Kafka Streams should consider upgrading directly to 4.1.1, which includes the fix for it.
+
+### Upgrading Servers to 4.1.0 from any version 3.3.x through 4.0.x
+
+### Notable changes in 4.1.0
+
+ * Apache Kafka 4.1 ships with a preview of Queues for Kafka ([KIP-932](https://cwiki.apache.org/confluence/x/4hA0Dw)). This feature introduces a new kind of group called share groups, as an alternative to consumer groups. Consumers in a share group cooperatively consume records from topics, without assigning each partition to just one consumer. Share groups also introduce per-record acknowledgement and counting of delivery attempts. Use share groups in cases where records are processed [...]
+ * **Common**
+ * The logger class name for LogCleaner has been updated from `kafka.log.LogCleaner` to `org.apache.kafka.storage.internals.log.LogCleaner` in the log4j2.yaml configuration file. Added loggers for `org.apache.kafka.storage.internals.log.LogCleaner$CleanerThread` and `org.apache.kafka.storage.internals.log.Cleaner` classes to CleanerAppender.
+ * The filename for rotated `state-change.log` files has been updated from `stage-change.log.[date]` to `state-change.log.[date]` in the log4j2.yaml configuration file.
+ * **Broker**
+ * The configuration `log.cleaner.enable` is deprecated. Users should no longer set it to `false` to prepare for future removal. After the removal, `log.cleaner.threads` will also have a lower bound of 1. For further details, please refer to [KIP-1148](https://cwiki.apache.org/confluence/x/XAyWF).
+ * The KIP-966 part 1: Eligible Leader Replicas(ELR) will be enabled by default on the new clusters. After the ELR feature enabled, the previously set `min.insync.replicas` value at the broker-level config will be removed. Please set at the cluster-level if necessary. For further details, please refer to [here](/42/documentation.html#eligible_leader_replicas).
+ * **Producer**
+ * The `flush` method now detects potential deadlocks and prohibits its use inside a callback. This change prevents unintended blocking behavior, which was a known risk in earlier versions.
+ * **Command**
+ * The `force` option of `ConfigCommand` has been removed, as it has been non-operational since version 0.10.1.0.
+ * **Admin**
+ * The `listConsumerGroups()` and `listConsumerGroups(ListConsumerGroupsOptions)` methods in `Admin` are deprecated, and will be removed in the next major version. Use `Admin.listGroups(ListGroupsOptions.forConsumerGroups())` instead.
+ * **Kafka Streams**
+ * The `window.size.ms` and `window.inner.serde.class` in `StreamsConfig` are deprecated. Use the corresponding string constants defined in `TimeWindowedSerializer`, `TimeWindowedDeserializer`, `SessionWindowedSerializer` and `SessionWindowedDeserializer` instead.
+
+
+
+## Upgrading to 4.0.1
+
+### Upgrading Clients to 4.0.1
+
+**For a rolling upgrade:**
+
+ 1. Upgrade the clients one at a time: shut down the client, update the code, and restart it.
+ 2. Clients (including Streams and Connect) must be on version 2.1 or higher before upgrading to 4.0. Many deprecated APIs were removed in Kafka 4.0. For more information about the compatibility, please refer to the [compatibility matrix](/42/documentation/compatibility.html) or [KIP-1124](https://cwiki.apache.org/confluence/x/y4kgF).
+
+
+
+### Upgrading Servers to 4.0.1 from any version 3.3.x through 3.9.x
+
+Note: Apache Kafka 4.0 only supports KRaft mode - ZooKeeper mode has been removed. As such, **broker upgrades to 4.0.0 (and higher) require KRaft mode and the software and metadata versions must be at least 3.3.x** (the first version when KRaft mode was deemed production ready). For clusters in KRaft mode with versions older than 3.3.x, we recommend upgrading to 3.9.x before upgrading to 4.0.x. Clusters in ZooKeeper mode have to be [migrated to KRaft mode](/42/documentation.html#kraft_zk [...]
+
+**For a rolling upgrade:**
+
+ 1. Upgrade the brokers one at a time: shut down the broker, update the code, and restart it. Once you have done so, the brokers will be running the latest version and you can verify that the cluster's behavior and performance meet expectations.
+ 2. Once the cluster's behavior and performance have been verified, finalize the upgrade by running ` bin/kafka-features.sh --bootstrap-server localhost:9092 upgrade --release-version 4.0 `
+ 3. Note that cluster metadata downgrade is not supported in this version since it has metadata changes. Every [MetadataVersion](https://github.com/apache/kafka/blob/trunk/server-common/src/main/java/org/apache/kafka/server/common/MetadataVersion.java) has a boolean parameter that indicates if there are metadata changes (i.e. `IBP_4_0_IV1(23, "4.0", "IV1", true)` means this version has metadata changes). Given your current and target versions, a downgrade is only possible if there are n [...]
+
+
+
+### Notable changes in 4.0.1
+
+ * The filename for rotated `state-change.log` files has been updated from `stage-change.log.[date]` to `state-change.log.[date]` in the log4j2.yaml configuration file. See [KAFKA-19576](https://issues.apache.org/jira/browse/KAFKA-19576) for details.
+ * Kafka Streams include a critical fix to upgrade from `KStreams#transformValues()` (remove with 4.0.0 release) to `KStreams#processValues()`. For more details, see the [migration guide](/42/documentation/streams/developer-guide/dsl-api.html#transformers-removal-and-migration-to-processors).
+
+
+
+### Notable changes in 4.0.0
+
+ * Old protocol API versions have been removed. Users should ensure brokers are version 2.1 or higher before upgrading Java clients (including Connect and Kafka Streams which use the clients internally) to 4.0. Similarly, users should ensure their Java clients (including Connect and Kafka Streams) version is 2.1 or higher before upgrading brokers to 4.0. Finally, care also needs to be taken when it comes to kafka clients that are not part of Apache Kafka, please see [KIP-896](https://cw [...]
+ * Apache Kafka 4.0 only supports KRaft mode - ZooKeeper mode has been removed. About version upgrade, check [Upgrading to 4.0.1 from any version 3.3.x through 3.9.x](/42/documentation.html#upgrade_4_0_1) for more info.
+ * Apache Kafka 4.0 ships with a brand-new group coordinator implementation (See [here](https://cwiki.apache.org/confluence/x/HhD1D)). Functionally speaking, it implements all the same APIs. There are reasonable defaults, but the behavior of the new group coordinator can be tuned by setting the configurations with prefix `group.coordinator`.
+ * The Next Generation of the Consumer Rebalance Protocol ([KIP-848](https://cwiki.apache.org/confluence/x/HhD1D)) is now Generally Available (GA) in Apache Kafka 4.0. The protocol is automatically enabled on the server when the upgrade to 4.0 is finalized. Note that once the new protocol is used by consumer groups, the cluster can only be downgraded to version 3.4.1 or newer. For more information check [here](/42/documentation.html#consumer_rebalance_protocol).
+ * Transactions Server-Side Defense ([KIP-890](https://cwiki.apache.org/confluence/x/B40ODg)) brings a strengthened transactional protocol to Apache Kafka 4.0. The new and improved transactional protocol is enabled when the upgrade to 4.0 is finalized. When using 4.0 producer clients, the producer epoch is bumped on every transaction to ensure every transaction includes the intended messages and duplicates are not written as part of the next transaction. Downgrading the protocol is safe [...]
+ * Eligible Leader Replicas ([KIP-966 Part 1](https://cwiki.apache.org/confluence/x/mpOzDw)) enhances the replication protocol for the Apache Kafka 4.0. Now the KRaft controller keeps track of the data partition replicas that are not included in ISR but are safe to be elected as leader without data loss. Such replicas are stored in the partition metadata as the `Eligible Leader Replicas`(ELR). For more information check [here](/42/documentation.html#eligible_leader_replicas).
+ * Since Apache Kafka 4.0.0, we have added a system property (`org.apache.kafka.sasl.oauthbearer.allowed.urls`) to set the allowed URLs as SASL OAUTHBEARER token or jwks endpoints. By default, the value is an empty list. Users should explicitly set the allowed list if necessary.
+ * A number of deprecated classes, methods, configurations and tools have been removed.
+ * **Common**
+ * The `metrics.jmx.blacklist` and `metrics.jmx.whitelist` configurations were removed from the `org.apache.kafka.common.metrics.JmxReporter` Please use `metrics.jmx.exclude` and `metrics.jmx.include` respectively instead.
+ * The `auto.include.jmx.reporter` configuration was removed. The `metric.reporters` configuration is now set to `org.apache.kafka.common.metrics.JmxReporter` by default.
+ * The constructor `org.apache.kafka.common.metrics.JmxReporter` with string argument was removed. See [KIP-606](https://cwiki.apache.org/confluence/x/SxIRCQ) for details.
+ * The `bufferpool-wait-time-total`, `io-waittime-total`, and `iotime-total` metrics were removed. Please use `bufferpool-wait-time-ns-total`, `io-wait-time-ns-total`, and `io-time-ns-total` metrics as replacements, respectively.
+ * The `kafka.common.requests.DescribeLogDirsResponse.LogDirInfo` class was removed. Please use the `kafka.clients.admin.DescribeLogDirsResult.descriptions()` class and `kafka.clients.admin.DescribeLogDirsResult.allDescriptions()` instead.
+ * The `kafka.common.requests.DescribeLogDirsResponse.ReplicaInfo` class was removed. Please use the `kafka.clients.admin.DescribeLogDirsResult.descriptions()` class and `kafka.clients.admin.DescribeLogDirsResult.allDescriptions()` instead.
+ * The `org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler` class was removed. Please use the `org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler` class instead.
+ * The `org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler` class was removed. Please use the `org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler` class instead.
+ * The `org.apache.kafka.common.errors.NotLeaderForPartitionException` class was removed. The `org.apache.kafka.common.errors.NotLeaderOrFollowerException` is returned if a request could not be processed because the broker is not the leader or follower for a topic partition.
+ * The `org.apache.kafka.clients.producer.internals.DefaultPartitioner` and `org.apache.kafka.clients.producer.UniformStickyPartitioner` classes were removed.
+ * The `log.message.format.version` and `message.format.version` configs were removed.
+ * The function `onNewBatch` in `org.apache.kafka.clients.producer.Partitioner` class was removed.
+ * The default properties files for KRaft mode are no longer stored in the separate `config/kraft` directory since Zookeeper has been removed. These files have been consolidated with other configuration files. Now all configuration files are in `config` directory.
+ * The valid format for `--bootstrap-server` only supports comma-separated value, such as `host1:port1,host2:port2,...`. Providing other formats, like space-separated bootstrap servers (e.g., `host1:port1 host2:port2 host3:port3`), will result in an exception, even though this was allowed in Apache Kafka versions prior to 4.0.
+ * **Broker**
+ * The `delegation.token.master.key` configuration was removed. Please use `delegation.token.secret.key` instead.
+ * The `offsets.commit.required.acks` configuration was removed. See [KIP-1041](https://cwiki.apache.org/confluence/x/9YobEg) for details.
+ * The `log.message.timestamp.difference.max.ms` configuration was removed. Please use `log.message.timestamp.before.max.ms` and `log.message.timestamp.after.max.ms` instead. See [KIP-937](https://cwiki.apache.org/confluence/x/thQ0Dw) for details.
+ * The `remote.log.manager.copier.thread.pool.size` configuration default value was changed to 10 from -1. Values of -1 are no longer valid; a minimum value of 1 or higher is required. See [KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ)
+ * The `remote.log.manager.expiration.thread.pool.size` configuration default value was changed to 10 from -1. Values of -1 are no longer valid; a minimum value of 1 or higher is required. See [KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ)
+ * The `remote.log.manager.thread.pool.size` configuration default value was changed to 2 from 10. See [KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ)
+ * The minimum `segment.bytes/log.segment.bytes` has changed from 14 bytes to 1MB. See [KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ)
+ * **MirrorMaker**
+ * The original MirrorMaker (MM1) and related classes were removed. Please use the Connect-based MirrorMaker (MM2), as described in the [Geo-Replication section.](/42/documentation/#georeplication).
+ * The `use.incremental.alter.configs` configuration was removed from `MirrorSourceConnector`. The modified behavior is now identical to the previous `required` configuration, therefore users should ensure that brokers in the target cluster are at least running 2.3.0.
+ * The `add.source.alias.to.metrics` configuration was removed from `MirrorSourceConnector`. The source cluster alias is now always added to the metrics.
+ * The `config.properties.blacklist` was removed from the `org.apache.kafka.connect.mirror.MirrorSourceConfig` Please use `config.properties.exclude` instead.
+ * The `topics.blacklist` was removed from the `org.apache.kafka.connect.mirror.MirrorSourceConfig` Please use `topics.exclude` instead.
+ * The `groups.blacklist` was removed from the `org.apache.kafka.connect.mirror.MirrorSourceConfig` Please use `groups.exclude` instead.
+ * **Tools**
+ * The `kafka.common.MessageReader` class was removed. Please use the [`org.apache.kafka.tools.api.RecordReader`](/42/javadoc/org/apache/kafka/tools/api/RecordReader.html) interface to build custom readers for the `kafka-console-producer` tool.
+ * The `kafka.tools.DefaultMessageFormatter` class was removed. Please use the `org.apache.kafka.tools.consumer.DefaultMessageFormatter` class instead.
+ * The `kafka.tools.LoggingMessageFormatter` class was removed. Please use the `org.apache.kafka.tools.consumer.LoggingMessageFormatter` class instead.
+ * The `kafka.tools.NoOpMessageFormatter` class was removed. Please use the `org.apache.kafka.tools.consumer.NoOpMessageFormatter` class instead.
+ * The `--whitelist` option was removed from the `kafka-console-consumer` command line tool. Please use `--include` instead.
+ * Redirections from the old tools packages have been removed: `kafka.admin.FeatureCommand`, `kafka.tools.ClusterTool`, `kafka.tools.EndToEndLatency`, `kafka.tools.StateChangeLogMerger`, `kafka.tools.StreamsResetter`, `kafka.tools.JmxTool`.
+ * The `--authorizer`, `--authorizer-properties`, and `--zk-tls-config-file` options were removed from the `kafka-acls` command line tool. Please use `--bootstrap-server` or `--bootstrap-controller` instead.
+ * The `kafka.serializer.Decoder` trait was removed, please use the [`org.apache.kafka.tools.api.Decoder`](/42/javadoc/org/apache/kafka/tools/api/Decoder.html) interface to build custom decoders for the `kafka-dump-log` tool.
+ * The `kafka.coordinator.group.OffsetsMessageFormatter` class was removed. Please use the `org.apache.kafka.tools.consumer.OffsetsMessageFormatter` class instead.
+ * The `kafka.coordinator.group.GroupMetadataMessageFormatter` class was removed. Please use the `org.apache.kafka.tools.consumer.GroupMetadataMessageFormatter` class instead.
+ * The `kafka.coordinator.transaction.TransactionLogMessageFormatter` class was removed. Please use the `org.apache.kafka.tools.consumer.TransactionLogMessageFormatter` class instead.
+ * The `--topic-white-list` option was removed from the `kafka-replica-verification` command line tool. Please use `--topics-include` instead.
+ * The `--broker-list` option was removed from the `kafka-verifiable-consumer` command line tool. Please use `--bootstrap-server` instead.
+ * `kafka-configs.sh` now uses incrementalAlterConfigs API to alter broker configurations instead of the deprecated alterConfigs API, and it will fall directly if the broker doesn't support incrementalAlterConfigs API, which means the broker version is prior to 2.3.x. See [KIP-1011](https://cwiki.apache.org/confluence/x/wIn5E) for more details.
+ * The `kafka.admin.ZkSecurityMigrator` tool was removed.
+ * **Connect**
+ * The `whitelist` and `blacklist` configurations were removed from the `org.apache.kafka.connect.transforms.ReplaceField` transformation. Please use `include` and `exclude` respectively instead.
+ * The `onPartitionsRevoked(Collection<TopicPartition>)` and `onPartitionsAssigned(Collection<TopicPartition>)` methods were removed from `SinkTask`.
+ * The `commitRecord(SourceRecord)` method was removed from `SourceTask`.
+ * **Consumer**
+ * The `poll(long)` method was removed from the consumer. Please use `poll(Duration)` instead. Note that there is a difference in behavior between the two methods. The `poll(Duration)` method does not block beyond the timeout awaiting partition assignment, whereas the earlier `poll(long)` method used to wait beyond the timeout.
+ * The `committed(TopicPartition)` and `committed(TopicPartition, Duration)` methods were removed from the consumer. Please use `committed(Set<TopicPartition>)` and `committed(Set<TopicPartition>, Duration)` instead.
+ * The `setException(KafkaException)` method was removed from the `org.apache.kafka.clients.consumer.MockConsumer`. Please use `setPollException(KafkaException)` instead.
+ * **Producer**
+ * The `enable.idempotence` configuration will no longer automatically fall back when the `max.in.flight.requests.per.connection` value exceeds 5.
+ * The deprecated `sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata>, String)` method has been removed from the Producer API.
+ * The default `linger.ms` changed from 0 to 5 in Apache Kafka 4.0 as the efficiency gains from larger batches typically result in similar or lower producer latency despite the increased linger.
+ * **Admin client**
+ * The `alterConfigs` method was removed from the `org.apache.kafka.clients.admin.Admin`. Please use `incrementalAlterConfigs` instead.
+ * The `org.apache.kafka.common.ConsumerGroupState` enumeration and related methods have been deprecated. Please use `GroupState` instead which applies to all types of group.
+ * The `Admin.describeConsumerGroups` method used to return a `ConsumerGroupDescription` in state `DEAD` if the group ID was not found. In Apache Kafka 4.0, the `GroupIdNotFoundException` is thrown instead as part of the support for new types of group.
+ * The `org.apache.kafka.clients.admin.DeleteTopicsResult.values()` method was removed. Please use `org.apache.kafka.clients.admin.DeleteTopicsResult.topicNameValues()` instead.
+ * The `org.apache.kafka.clients.admin.TopicListing.TopicListing(String, boolean)` method was removed. Please use `org.apache.kafka.clients.admin.TopicListing.TopicListing(String, Uuid, boolean)` instead.
+ * The `org.apache.kafka.clients.admin.ListConsumerGroupOffsetsOptions.topicPartitions(List<TopicPartition>)` method was removed. Please use `org.apache.kafka.clients.admin.Admin.listConsumerGroupOffsets(Map<String, ListConsumerGroupOffsetsSpec>, ListConsumerGroupOffsetsOptions)` instead.
+ * The deprecated `dryRun` methods were removed from the `org.apache.kafka.clients.admin.UpdateFeaturesOptions`. Please use `validateOnly` instead.
+ * The constructor `org.apache.kafka.clients.admin.FeatureUpdate` with short and boolean arguments was removed. Please use the constructor that accepts short and the specified `UpgradeType` enum instead.
+ * The `allowDowngrade` method was removed from the `org.apache.kafka.clients.admin.FeatureUpdate`.
+ * The `org.apache.kafka.clients.admin.DescribeTopicsResult.DescribeTopicsResult(Map<String, KafkaFuture<TopicDescription>>)` method was removed. Please use `org.apache.kafka.clients.admin.DescribeTopicsResult.DescribeTopicsResult(Map<Uuid, KafkaFuture<TopicDescription>>, Map<String, KafkaFuture<TopicDescription>>)` instead.
+ * The `values()` method was removed from the `org.apache.kafka.clients.admin.DescribeTopicsResult`. Please use `topicNameValues()` instead.
+ * The `all()` method was removed from the `org.apache.kafka.clients.admin.DescribeTopicsResult`. Please use `allTopicNames()` instead.
+ * **Kafka Streams**
+ * All public APIs, deprecated in Apache Kafka 3.6 or an earlier release, have been removed, with the exception of `JoinWindows.of()` and `JoinWindows#grace()`. See [KAFKA-17531](https://issues.apache.org/jira/browse/KAFKA-17531) for details.
+ * The most important changes are highlighted in the [Kafka Streams upgrade guide](/42/documentation/streams/upgrade-guide.html#streams_api_changes_400).
+ * For a full list of changes, see [KAFKA-12822](https://issues.apache.org/jira/browse/KAFKA-12822).
+ * If you are using `KStream#transformValues()` which was removed with Apache Kafka 4.0.0 release, and you need to rewrite your program to use `KStreams#processValues()` instead, pay close attention to the [migration guide](/42/documentation/streams/developer-guide/dsl-api.html#transformers-removal-and-migration-to-processors).
+ * Other changes:
+ * The minimum Java version required by clients and Kafka Streams applications has been increased from Java 8 to Java 11 while brokers, connect and tools now require Java 17. See [KIP-750](https://cwiki.apache.org/confluence/x/P4vOCg) and [KIP-1013](https://cwiki.apache.org/confluence/x/Bov5E) for more details.
+ * Java 23 support has been added in Apache Kafka 4.0.
+ * Scala 2.12 support has been removed in Apache Kafka 4.0. See [KIP-751](https://cwiki.apache.org/confluence/x/OovOCg) for more details
+ * Logging framework has been migrated from Log4j to Log4j2. Users can use the log4j-transform-cli tool to automatically convert their existing Log4j configuration files to Log4j2 format. See [log4j-transform-cli](https://logging.staged.apache.org/log4j/transform/cli.html#log4j-transform-cli) for more details. Log4j2 provides limited compatibility for Log4j configurations. See [Use Log4j 1 to Log4j 2 bridge](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#ConfigurationCo [...]
+ * KafkaLog4jAppender has been removed, users should migrate to the log4j2 appender See [KafkaAppender](https://logging.apache.org/log4j/2.x/manual/appenders.html#KafkaAppender) for more details
+ * The `--delete-config` option in the `kafka-topics` command line tool has been deprecated.
+ * For implementors of RemoteLogMetadataManager (RLMM), a new API `nextSegmentWithTxnIndex` is introduced in RLMM to allow the implementation to return the next segment metadata with a transaction index. This API is used when the consumers are enabled with isolation level as READ_COMMITTED. See [KIP-1058](https://cwiki.apache.org/confluence/x/BwuTEg) for more details.
+ * The criteria for identifying internal topics in ReplicationPolicy and DefaultReplicationPolicy have been updated to enable the replication of topics that appear to be internal but aren't truly internal to Kafka and Mirror Maker 2. See [KIP-1074](https://cwiki.apache.org/confluence/x/jA3OEg) for more details.
+ * [KIP-714](https://cwiki.apache.org/confluence/x/2xRRCg) is now enabled for Kafka Streams via [KIP-1076](https://cwiki.apache.org/confluence/x/XA-OEg). This allows to not only collect the metric of the internally used clients of a Kafka Streams application via a broker-side plugin, but also to collect the [metrics](/42/documentation/#kafka_streams_monitoring) of the Kafka Streams runtime itself.
+ * The default value of `num.recovery.threads.per.data.dir` has been changed from 1 to 2. The impact of this is faster recovery post unclean shutdown at the expense of extra IO cycles. See [KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ)
+ * The default value of `message.timestamp.after.max.ms` has been changed from Long.Max to 1 hour. The impact of this messages with a timestamp of more than 1 hour in the future will be rejected when message.timestamp.type=CreateTime is set. See [KIP-1030](https://cwiki.apache.org/confluence/x/FAqpEQ)
+ * Introduced in [KIP-890](https://cwiki.apache.org/confluence/x/B40ODg), the `TransactionAbortableException` enhances error handling within transactional operations by clearly indicating scenarios where transactions should be aborted due to errors. It is important for applications to properly manage both `TimeoutException` and `TransactionAbortableException` when working with transaction producers.
+ * **TimeoutException:** This exception indicates that a transactional operation has timed out. Given the risk of message duplication that can arise from retrying operations after a timeout (potentially violating exactly-once semantics), applications should treat timeouts as reasons to abort the ongoing transaction.
+ * **TransactionAbortableException:** Specifically introduced to signal errors that should lead to transaction abortion, ensuring this exception is properly handled is critical for maintaining the integrity of transactional processing.
+ * To ensure seamless operation and compatibility with future Kafka versions, developers are encouraged to update their error-handling logic to treat both exceptions as triggers for aborting transactions. This approach is pivotal for preserving exactly-once semantics.
+ * See [KIP-890](https://cwiki.apache.org/confluence/x/B40ODg) and [KIP-1050](https://cwiki.apache.org/confluence/x/8ItyEg) for more details
+ * The filename for rotated `state-change.log` files incorrectly rotates to `stage-change.log.[date]` (changing state to stage). This issue is corrected in 4.0.1. See [KAFKA-19576](https://issues.apache.org/jira/browse/KAFKA-19576) for details.
+
+
+
+## Upgrading to 3.9.0 and older versions
+
+See [Upgrading From Previous Versions](/39/documentation/#upgrade) in the 3.9 documentation.
diff --git a/docs/getting-started/uses.md b/docs/getting-started/uses.md
new file mode 100644
index 00000000000..06ba5c689d0
--- /dev/null
+++ b/docs/getting-started/uses.md
@@ -0,0 +1,63 @@
+---
+title: Use Cases
+description:
+weight: 2
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Here is a description of a few of the popular use cases for Apache Kafka®. For an overview of a number of these areas in action, see [this blog post](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/).
+
+## Messaging
+
+Kafka works well as a replacement for a more traditional message broker. Message brokers are used for a variety of reasons (to decouple processing from data producers, to buffer unprocessed messages, etc). In comparison to most messaging systems Kafka has better throughput, built-in partitioning, replication, and fault-tolerance which makes it a good solution for large scale message processing applications.
+
+In our experience messaging uses are often comparatively low-throughput, but may require low end-to-end latency and often depend on the strong durability guarantees Kafka provides.
+
+In this domain Kafka is comparable to traditional messaging systems such as [ActiveMQ](https://activemq.apache.org) or [RabbitMQ](https://www.rabbitmq.com).
+
+## Website Activity Tracking
+
+The original use case for Kafka was to be able to rebuild a user activity tracking pipeline as a set of real-time publish-subscribe feeds. This means site activity (page views, searches, or other actions users may take) is published to central topics with one topic per activity type. These feeds are available for subscription for a range of use cases including real-time processing, real-time monitoring, and loading into Hadoop or offline data warehousing systems for offline processing an [...]
+
+Activity tracking is often very high volume as many activity messages are generated for each user page view.
+
+## Metrics
+
+Kafka is often used for operational monitoring data. This involves aggregating statistics from distributed applications to produce centralized feeds of operational data.
+
+## Log Aggregation
+
+Many people use Kafka as a replacement for a log aggregation solution. Log aggregation typically collects physical log files off servers and puts them in a central place (a file server or HDFS perhaps) for processing. Kafka abstracts away the details of files and gives a cleaner abstraction of log or event data as a stream of messages. This allows for lower-latency processing and easier support for multiple data sources and distributed data consumption. In comparison to log-centric syste [...]
+
+## Stream Processing
+
+Many users of Kafka process data in processing pipelines consisting of multiple stages, where raw input data is consumed from Kafka topics and then aggregated, enriched, or otherwise transformed into new topics for further consumption or follow-up processing. For example, a processing pipeline for recommending news articles might crawl article content from RSS feeds and publish it to an "articles" topic; further processing might normalize or deduplicate this content and publish the clean [...]
+
+## Event Sourcing
+
+[Event sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) is a style of application design where state changes are logged as a time-ordered sequence of records. Kafka's support for very large stored log data makes it an excellent backend for an application built in this style.
+
+## Commit Log
+
+Kafka can serve as a kind of external commit-log for a distributed system. The log helps replicate data between nodes and acts as a re-syncing mechanism for failed nodes to restore their data. The [log compaction](/documentation.html#compaction) feature in Kafka helps support this usage. In this usage Kafka is similar to [Apache BookKeeper](https://bookkeeper.apache.org/) project.
diff --git a/docs/getting-started/zk2kraft.md b/docs/getting-started/zk2kraft.md
new file mode 100644
index 00000000000..3ef7d5017a4
--- /dev/null
+++ b/docs/getting-started/zk2kraft.md
@@ -0,0 +1,237 @@
+---
+title: KRaft vs ZooKeeper
+description:
+weight: 6
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+# Differences Between KRaft mode and ZooKeeper mode
+
+# Removed ZooKeeper Features
+
+This section documents differences in behavior between KRaft mode and ZooKeeper mode. Specifically, several configurations, metrics and features have changed or are no longer required in KRaft mode. To migrate an existing cluster from ZooKeeper mode to KRaft mode, please refer to the [ZooKeeper to KRaft Migration](/39/documentation.html#kraft_zk_migration) section.
+
+## Configurations
+
+ * Removed password encoder-related configurations. These configurations were used in ZooKeeper mode to define the key and backup key for encrypting sensitive data (e.g., passwords), specify the algorithm and key generation method for password encryption (e.g., AES, RSA), and control the key length and encryption strength.
+
+ * `password.encoder.secret`
+ * `password.encoder.old.secret`
+ * `password.encoder.keyfactory.algorithm`
+ * `password.encoder.cipher.algorithm`
+ * `password.encoder.key.length`
+ * `password.encoder.iterations`
+
+In KRaft mode, Kafka stores sensitive data in records, and the data is not encrypted in Kafka.
+
+ * Removed `control.plane.listener.name`. Kafka relies on ZooKeeper to manage metadata, but some internal operations (e.g., communication between controllers (a.k.a., broker controller) and brokers) still require Kafka’s internal control plane for coordination.
+
+In KRaft mode, Kafka eliminates its dependency on ZooKeeper, and the control plane functionality is fully integrated into Kafka itself. The process roles are clearly separated: brokers handle data-related requests, while the controllers (a.k.a., quorum controller) manages metadata-related requests. The controllers use the Raft protocol for internal communication, which operates differently from the ZooKeeper model. Use the following parameters to configure the control plane listener:
+
+ * `controller.listener.names`
+ * `listeners`
+ * `listener.security.protocol.map`
+ * Removed graceful broker shutdowns-related configurations. These configurations were used in ZooKeeper mode to define the maximum number of retries and the retry backoff time for controlled shutdowns. It can reduce the risk of unplanned leader changes and data inconsistencies.
+
+ * `controlled.shutdown.max.retries`
+ * `controlled.shutdown.retry.backoff.ms`
+
+In KRaft mode, Kafka uses the Raft protocol to manage metadata. The broker shutdown process differs from ZooKeeper mode as it is managed by the quorum-based controller. The shutdown process is more reliable and efficient due to automated leader transfers and metadata updates handled by the controller.
+
+ * Removed the broker id generation-related configurations. These configurations were used in ZooKeeper mode to specify the broker id auto generation and control the broker id generation process.
+
+ * `reserved.broker.max.id`
+ * `broker.id.generation.enable`
+
+Kafka uses the node id in KRaft mode to identify servers.
+
+ * `node.id`
+ * Removed broker protocol version-related configurations. These configurations were used in ZooKeeper mode to define communication protocol version between brokers. In KRaft mode, Kafka uses `metadata.version` to control the feature level of the cluster, which can be managed using `bin/kafka-features.sh`.
+
+ * `inter.broker.protocol.version`
+ * Removed dynamic configurations which relied on ZooKeeper. In KRaft mode, to change these configurations, you need to restart the broker/controller.
+
+ * `advertised.listeners`
+ * Removed the leader imbalance configuration used only in ZooKeeper. `leader.imbalance.per.broker.percentage` was used to limit the preferred leader election frequency in ZooKeeper.
+
+ * `leader.imbalance.per.broker.percentage`
+ * Removed ZooKeeper related configurations.
+
+ * `zookeeper.connect`
+ * `zookeeper.session.timeout.ms`
+ * `zookeeper.connection.timeout.ms`
+ * `zookeeper.set.acl`
+ * `zookeeper.max.in.flight.requests`
+ * `zookeeper.ssl.client.enable`
+ * `zookeeper.clientCnxnSocket`
+ * `zookeeper.ssl.keystore.location`
+ * `zookeeper.ssl.keystore.password`
+ * `zookeeper.ssl.keystore.type`
+ * `zookeeper.ssl.truststore.location`
+ * `zookeeper.ssl.truststore.password`
+ * `zookeeper.ssl.truststore.type`
+ * `zookeeper.ssl.protocol`
+ * `zookeeper.ssl.enabled.protocols`
+ * `zookeeper.ssl.cipher.suites`
+ * `zookeeper.ssl.endpoint.identification.algorithm`
+ * `zookeeper.ssl.crl.enable`
+ * `zookeeper.ssl.ocsp.enable`
+
+
+
+## Dynamic Log Levels
+
+ * The dynamic log levels feature allows you to change the log4j settings of a running broker or controller process without restarting it. The command-line syntax for setting dynamic log levels on brokers has not changed in KRaft mode. Here is an example of setting the log level on a broker:
+
+
+ ./bin/kafka-configs.sh --bootstrap-server localhost:9092 \
+ --entity-type broker-loggers \
+ --entity-name 1 \
+ --alter \
+ --add-config org.apache.kafka.raft.KafkaNetworkChannel=TRACE
+
+
+ * When setting dynamic log levels on the controllers, the `--bootstrap-controller` flag must be used. Here is an example of setting the log level ona controller:
+
+
+ ./bin/kafka-configs.sh --bootstrap-controller localhost:9093 \
+ --entity-type broker-loggers \
+ --entity-name 1 \
+ --alter \
+ --add-config org.apache.kafka.raft.KafkaNetworkChannel=TRACE
+
+
+
+Note that the entity-type must be specified as `broker-loggers`, even though we are changing a controller's log level rather than a broker's log level.
+
+ * When changing the log level of a combined node, which has both broker and controller roles, either --bootstrap-servers or --bootstrap-controllers may be used. Combined nodes have only a single set of log levels; there are not different log levels for the broker and controller parts of the process.
+
+
+
+
+## Dynamic Controller Configurations
+
+ * Some Kafka configurations can be changed dynamically, without restarting the process. The command-line syntax for setting dynamic log levels on brokers has not changed in KRaft mode. Here is an example of setting the number of IO threads on a broker:
+
+
+ ./bin/kafka-configs.sh --bootstrap-server localhost:9092 \
+ --entity-type brokers \
+ --entity-name 1 \
+ --alter \
+ --add-config num.io.threads=5
+
+
+ * Controllers will apply all applicable cluster-level dynamic configurations. For example, the following command-line will change the `max.connections` setting on all of the brokers and all of the controllers in the cluster:
+
+
+ ./bin/kafka-configs.sh --bootstrap-server localhost:9092 \
+ --entity-type brokers \
+ --entity-default \
+ --alter \
+ --add-config max.connections=10000
+
+
+
+It is not currently possible to apply a dynamic configuration on only a single controller.
+
+
+
+
+# Metrics
+
+ * Removed the following metrics related to ZooKeeper. `ControlPlaneNetworkProcessorAvgIdlePercent` is to monitor the average fraction of time the network processors are idle. The other `ControlPlaneExpiredConnectionsKilledCount` is to monitor the total number of connections disconnected, across all processors.
+
+ * `ControlPlaneNetworkProcessorAvgIdlePercent`
+ * `ControlPlaneExpiredConnectionsKilledCount`
+
+In KRaft mode, Kafka also provides metrics to monitor the network processors and expired connections. Use the following metrics to monitor the network processors and expired connections:
+
+ * `NetworkProcessorAvgIdlePercent`
+ * `ExpiredConnectionsKilledCount`
+ * Removed the metrics which are only used in ZooKeeper mode.
+
+ * `kafka.controller:type=ControllerChannelManager,name=QueueSize`
+ * `kafka.controller:type=ControllerChannelManager,name=RequestRateAndQueueTimeMs`
+ * `kafka.controller:type=ControllerEventManager,name=EventQueueSize`
+ * `kafka.controller:type=ControllerEventManager,name=EventQueueTimeMs`
+ * `kafka.controller:type=ControllerStats,name=AutoLeaderBalanceRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=ControlledShutdownRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=ControllerChangeRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=ControllerShutdownRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=IdleRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=IsrChangeRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=LeaderAndIsrResponseReceivedRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=ListPartitionReassignmentRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=LogDirChangeRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=ManualLeaderBalanceRateAndTimeMs`
+ * `kafka.controller:type=KafkaController,name=MigratingZkBrokerCount`
+ * `kafka.controller:type=ControllerStats,name=PartitionReassignmentRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=TopicChangeRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=TopicDeletionRateAndTimeMs`
+ * `kafka.controller:type=KafkaController,name=TopicsIneligibleToDeleteCount`
+ * `kafka.controller:type=ControllerStats,name=TopicUncleanLeaderElectionEnableRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=UncleanLeaderElectionEnableRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=UncleanLeaderElectionsPerSec`
+ * `kafka.controller:type=ControllerStats,name=UpdateFeaturesRateAndTimeMs`
+ * `kafka.controller:type=ControllerStats,name=UpdateMetadataResponseReceivedRateAndTimeMs`
+ * `kafka.controller:type=KafkaController,name=ActiveBrokerCount`
+ * `kafka.controller:type=KafkaController,name=ActiveControllerCount`
+ * `kafka.controller:type=KafkaController,name=ControllerState`
+ * `kafka.controller:type=KafkaController,name=FencedBrokerCount`
+ * `kafka.controller:type=KafkaController,name=GlobalPartitionCount`
+ * `kafka.controller:type=KafkaController,name=GlobalTopicCount`
+ * `kafka.controller:type=KafkaController,name=OfflinePartitionsCount`
+ * `kafka.controller:type=KafkaController,name=PreferredReplicaImbalanceCount`
+ * `kafka.controller:type=KafkaController,name=ReplicasIneligibleToDeleteCount`
+ * `kafka.controller:type=KafkaController,name=ReplicasToDeleteCount`
+ * `kafka.controller:type=KafkaController,name=TopicsToDeleteCount`
+ * `kafka.controller:type=KafkaController,name=ZkMigrationState`
+ * `kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=ElectLeader`
+ * `kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=topic`
+ * `kafka.server:type=DelayedOperationPurgatory,name=NumDelayedOperations,delayedOperation=ElectLeader`
+ * `kafka.server:type=DelayedOperationPurgatory,name=NumDelayedOperations,delayedOperation=topic`
+ * `kafka.server:type=SessionExpireListener,name=SessionState`
+ * `kafka.server:type=SessionExpireListener,name=ZooKeeperAuthFailuresPerSec`
+ * `kafka.server:type=SessionExpireListener,name=ZooKeeperDisconnectsPerSec`
+ * `kafka.server:type=SessionExpireListener,name=ZooKeeperExpiresPerSec`
+ * `kafka.server:type=SessionExpireListener,name=ZooKeeperReadOnlyConnectsPerSec`
+ * `kafka.server:type=SessionExpireListener,name=ZooKeeperSaslAuthenticationsPerSec`
+ * `kafka.server:type=SessionExpireListener,name=ZooKeeperSyncConnectsPerSec`
+ * `kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs`
+
+
+
+# Behavioral Change Reference
+
+This document catalogs the functional and operational differences between ZooKeeper mode and KRaft mode.
+
+ * **Configuration Value Size Limitation** : KRaft mode restricts configuration values to a maximum size of `Short.MAX_VALUE`, which prevents using the append operation to create larger configuration values.
+ * **Policy Class Deployment** : In KRaft mode, the `CreateTopicPolicy` and `AlterConfigPolicy` plugins run on the controller instead of the broker. This requires users to deploy the policy class JAR files on the controller and configure the parameters (`create.topic.policy.class.name` and `alter.config.policy.class.name`) on the controller.
+
+Note: If migrating from ZooKeeper mode, ensure policy JARs are moved from brokers to controllers.
+
+ * **Custom implementations of`KafkaPrincipalBuilder`**: In KRaft mode, custom implementations of `KafkaPrincipalBuilder` must also implement `KafkaPrincipalSerde`; otherwise brokers will not be able to forward requests to the controller.
+
+
diff --git a/docs/implementation.html b/docs/implementation.html
deleted file mode 100644
index 3be539e0ba8..00000000000
--- a/docs/implementation.html
+++ /dev/null
@@ -1,205 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script id="implementation-template" type="text/x-handlebars-template">
- <h3 class="anchor-heading"><a id="networklayer" class="anchor-link"></a><a href="#networklayer">5.1 Network Layer</a></h3>
- <p>
- The network layer is a fairly straight-forward NIO server, and will not be described in great detail. The sendfile implementation is done by giving the <code>TransferableRecords</code> interface a <code>writeTo</code> method. This allows the file-backed message set to use the more efficient <code>transferTo</code> implementation instead of an in-process buffered write. The threading model is a single acceptor thread and <i>N</i> processor threads which handle a fixed number of connec [...]
- </p>
- <h3 class="anchor-heading"><a id="messages" class="anchor-link"></a><a href="#messages">5.2 Messages</a></h3>
- <p>
- Messages consist of a variable-length header, a variable-length opaque key byte array and a variable-length opaque value byte array. The format of the header is described in the following section.
- Leaving the key and value opaque is the right decision: there is a great deal of progress being made on serialization libraries right now, and any particular choice is unlikely to be right for all uses. Needless to say a particular application using Kafka would likely mandate a particular serialization type as part of its usage. The <code>RecordBatch</code> interface is simply an iterator over messages with specialized methods for bulk reading and writing to an NIO <code>Channel</code>.</p>
-
- <h3 class="anchor-heading"><a id="messageformat" class="anchor-link"></a><a href="#messageformat">5.3 Message Format</a></h3>
- <p>
- Messages (aka Records) are always written in batches. The technical term for a batch of messages is a record batch, and a record batch contains one or more records. In the degenerate case, we could have a record batch containing a single record.
- Record batches and records have their own headers. The format of each is described below. </p>
-
- <h4 class="anchor-heading"><a id="recordbatch" class="anchor-link"></a><a href="#recordbatch">5.3.1 Record Batch</a></h4>
- <p> The following is the on-disk format of a RecordBatch. </p>
- <pre><code class="language-text">baseOffset: int64
-batchLength: int32
-partitionLeaderEpoch: int32
-magic: int8 (current magic value is 2)
-crc: uint32
-attributes: int16
- bit 0~2:
- 0: no compression
- 1: gzip
- 2: snappy
- 3: lz4
- 4: zstd
- bit 3: timestampType
- bit 4: isTransactional (0 means not transactional)
- bit 5: isControlBatch (0 means not a control batch)
- bit 6: hasDeleteHorizonMs (0 means baseTimestamp is not set as the delete horizon for compaction)
- bit 7~15: unused
-lastOffsetDelta: int32
-baseTimestamp: int64
-maxTimestamp: int64
-producerId: int64
-producerEpoch: int16
-baseSequence: int32
-recordsCount: int32
-records: [Record]</code></pre>
- <p> Note that when compression is enabled, the compressed record data is serialized directly following the count of the number of records. </p>
-
- <p>batchLength represents the number of bytes from the current position (immediately after the batchLength field) to the end of the batch.
- In other words, the total size of a record batch on disk is batchLength + 12 bytes, which includes the 8-byte baseOffset and the 4-byte batchLength field itself.</p>
-
- <p>The CRC covers the data from the attributes to the end of the batch (i.e. all the bytes that follow the CRC). It is located after the magic byte, which
- means that clients must parse the magic byte before deciding how to interpret the bytes between the batch length and the magic byte. The partition leader
- epoch field is not included in the CRC computation to avoid the need to recompute the CRC when this field is assigned for every batch that is received by
- the broker. The CRC-32C (Castagnoli) polynomial is used for the computation.</p>
-
- <p>On compaction, we preserve the first and last offset/sequence numbers from the original batch when the log is cleaned. This is required in order to be able to restore the
- producer's state when the log is reloaded. If we did not retain the last sequence number, for example, then after a partition leader failure, the producer might see an OutOfSequence error. The base sequence number must
- be preserved for duplicate checking (the broker checks incoming Produce requests for duplicates by verifying that the first and last sequence numbers of the incoming batch match the last from that producer). As a result,
- it is possible to have empty batches in the log when all the records in the batch are cleaned but batch is still retained in order to preserve a producer's last sequence number. One oddity here is that the baseTimestamp
- field is not preserved during compaction, so it will change if the first record in the batch is compacted away.</p>
-
- <p>Compaction may also modify the baseTimestamp if the record batch contains records with a null payload or aborted transaction markers. The baseTimestamp will be set to the timestamp of when those records should be deleted
- with the delete horizon attribute bit also set.</p>
-
- <h5 class="anchor-heading"><a id="controlbatch" class="anchor-link"></a><a href="#controlbatch">5.3.1.1 Control Batches</a></h5>
- <p>A control batch contains a single record called the control record. Control records should not be passed on to applications. Instead, they are used by consumers to filter out aborted transactional messages.</p>
- <p> The key of a control record conforms to the following schema: </p>
- <pre><code class="language-text">version: int16 (current version is 0)
-type: int16 (0 indicates an abort marker, 1 indicates a commit)</code></pre>
- <p>The schema for the value of a control record is dependent on the type. The value is opaque to clients.</p>
-
- <h4 class="anchor-heading"><a id="record" class="anchor-link"></a><a href="#record">5.3.2 Record</a></h4>
- <p>The on-disk format of each record is delineated below. </p>
- <pre><code class="language-text">length: varint
-attributes: int8
- bit 0~7: unused
-timestampDelta: varlong
-offsetDelta: varint
-keyLength: varint
-key: byte[]
-valueLength: varint
-value: byte[]
-headersCount: varint
-Headers => [Header]</code></pre>
- <h5 class="anchor-heading"><a id="recordheader" class="anchor-link"></a><a href="#recordheader">5.3.2.1 Record Header</a></h5>
- <pre><code class="language-text">headerKeyLength: varint
-headerKey: String
-headerValueLength: varint
-Value: byte[]</code></pre>
- <p>The key of a record header is guaranteed to be non-null, while the value of a record header may be null. The order of headers in a record is preserved when producing and consuming.</p>
- <p>We use the same varint encoding as Protobuf. More information on the latter can be found <a href="https://developers.google.com/protocol-buffers/docs/encoding#varints">here</a>. The count of headers in a record
- is also encoded as a varint.</p>
-
- <h4 class="anchor-heading"><a id="messageset" class="anchor-link"></a><a href="#messageset">5.3.3 Old Message Format</a></h4>
- <p>
- Prior to Kafka 0.11, messages were transferred and stored in <i>message sets</i>. See <a href="https://kafka.apache.org/39/documentation/#messageset">Old Message Format</a> for more details.
- </p>
- <h3 class="anchor-heading"><a id="log" class="anchor-link"></a><a href="#log">5.4 Log</a></h3>
- <p>
- A log for a topic named "my-topic" with two partitions consists of two directories (namely <code>my-topic-0</code> and <code>my-topic-1</code>) populated with data files containing the messages for that topic. The format of the log files is a sequence of "log entries"; each log entry is a 4 byte integer <i>N</i> storing the message length which is followed by the <i>N</i> message bytes. Each message is uniquely identified by a 64-bit integer <i>offset</i> giving the byte position of [...]
- </p>
- <p>
- The exact binary format for records is versioned and maintained as a standard interface so record batches can be transferred between producer, broker, and client without recopying or conversion when desirable. The previous section included details about the on-disk format of records.
- </p>
- <p>
- The use of the message offset as the message id is unusual. Our original idea was to use a GUID generated by the producer, and maintain a mapping from GUID to offset on each broker. But since a consumer must maintain an ID for each server, the global uniqueness of the GUID provides no value. Furthermore, the complexity of maintaining the mapping from a random id to an offset requires a heavy weight index structure which must be synchronized with disk, essentially requiring a full per [...]
- </p>
- <img class="centered" src="/{{version}}/images/kafka_log.png">
- <h4 class="anchor-heading"><a id="impl_writes" class="anchor-link"></a><a href="#impl_writes">Writes</a></h4>
- <p>
- The log allows serial appends which always go to the last file. This file is rolled over to a fresh file when it reaches a configurable size (say 1GB). The log takes two configuration parameters: <i>M</i>, which gives the number of messages to write before forcing the OS to flush the file to disk, and <i>S</i>, which gives a number of seconds after which a flush is forced. This gives a durability guarantee of losing at most <i>M</i> messages or <i>S</i> seconds of data in the event o [...]
- </p>
- <h4 class="anchor-heading"><a id="impl_reads" class="anchor-link"></a><a href="#impl_reads">Reads</a></h4>
- <p>
- Reads are done by giving the 64-bit logical offset of a message and an <i>S</i>-byte max chunk size. This will return an iterator over the messages contained in the <i>S</i>-byte buffer. <i>S</i> is intended to be larger than any single message, but in the event of an abnormally large message, the read can be retried multiple times, each time doubling the buffer size, until the message is read successfully. A maximum message and buffer size can be specified to make the server reject [...]
- </p>
- <p>
- The actual process of reading from an offset requires first locating the log segment file in which the data is stored, calculating the file-specific offset from the global offset value, and then reading from that file offset. The search is done as a simple binary search variation against an in-memory range maintained for each file.
- </p>
- <p>
- The log provides the capability of getting the most recently written message to allow clients to start subscribing as of "right now". This is also useful in the case the consumer fails to consume its data within its SLA-specified number of days. In this case when the client attempts to consume a non-existent offset it is given an OutOfRangeException and can either reset itself or fail as appropriate to the use case.
- </p>
-
- <p> The following is the format of the results sent to the consumer.
-
- <pre><code class="language-text">MessageSetSend (fetch result)
-
-total length : 4 bytes
-error code : 2 bytes
-message 1 : x bytes
-...
-message n : x bytes</code></pre>
-
- <pre><code class="language-text">MultiMessageSetSend (multiFetch result)
-
-total length : 4 bytes
-error code : 2 bytes
-messageSetSend 1
-...
-messageSetSend n</code></pre>
- <h4 class="anchor-heading"><a id="impl_deletes" class="anchor-link"></a><a href="#impl_deletes">Deletes</a></h4>
- <p>
- Data is deleted one log segment at a time. The log manager applies two metrics to identify segments which are
- eligible for deletion: time and size. For time-based policies, the record timestamps are considered, with the
- largest timestamp in a segment file (order of records is not relevant) defining the retention time for the
- entire segment. Size-based retention is disabled by default. When enabled the log manager keeps deleting the
- oldest segment file until the overall size of the partition is within the configured limit again. If both
- policies are enabled at the same time, a segment that is eligible for deletion due to either policy will be
- deleted. To avoid locking reads while still allowing deletes that modify the segment list we use a copy-on-write
- style segment list implementation that provides consistent views to allow a binary search to proceed on an
- immutable static snapshot view of the log segments while deletes are progressing.
- </p>
- <h4 class="anchor-heading"><a id="impl_guarantees" class="anchor-link"></a><a href="#impl_guarantees">Guarantees</a></h4>
- <p>
- The log provides a configuration parameter <i>M</i> which controls the maximum number of messages that are written before forcing a flush to disk. On startup a log recovery process is run that iterates over all messages in the newest log segment and verifies that each message entry is valid. A message entry is valid if the sum of its size and offset are less than the length of the file AND the CRC32 of the message payload matches the CRC stored with the message. In the event corrupti [...]
- </p>
- <p>
- Note that two kinds of corruption must be handled: truncation in which an unwritten block is lost due to a crash, and corruption in which a nonsense block is ADDED to the file. The reason for this is that in general the OS makes no guarantee of the write order between the file inode and the actual block data so in addition to losing written data the file can gain nonsense data if the inode is updated with a new size but a crash occurs before the block containing that data is written. [...]
- </p>
-
- <h3 class="anchor-heading"><a id="distributionimpl" class="anchor-link"></a><a href="#distributionimpl">5.5 Distribution</a></h3>
- <h4 class="anchor-heading"><a id="impl_offsettracking" class="anchor-link"></a><a href="#impl_offsettracking">Consumer Offset Tracking</a></h4>
- <p>
- Kafka consumer tracks the maximum offset it has consumed in each partition and has the capability to commit offsets so
- that it can resume from those offsets in the event of a restart. Kafka provides the option to store all the offsets for
- a given consumer group in a designated broker (for that group) called the group coordinator. i.e., any consumer instance
- in that consumer group should send its offset commits and fetches to that group coordinator (broker). Consumer groups are
- assigned to coordinators based on their group names. A consumer can look up its coordinator by issuing a FindCoordinatorRequest
- to any Kafka broker and reading the FindCoordinatorResponse which will contain the coordinator details. The consumer
- can then proceed to commit or fetch offsets from the coordinator broker. In case the coordinator moves, the consumer will
- need to rediscover the coordinator. Offset commits can be done automatically or manually by consumer instance.
- </p>
-
- <p>
- When the group coordinator receives an OffsetCommitRequest, it appends the request to a special <a href="#compaction">compacted</a> Kafka topic named <i>__consumer_offsets</i>.
- The broker sends a successful offset commit response to the consumer only after all the replicas of the offsets topic receive the offsets.
- In case the offsets fail to replicate within a configurable timeout, the offset commit will fail and the consumer may retry the commit after backing off.
- The brokers periodically compact the offsets topic since it only needs to maintain the most recent offset commit per partition.
- The coordinator also caches the offsets in an in-memory table in order to serve offset fetches quickly.
- </p>
-
- <p>
- When the coordinator receives an offset fetch request, it simply returns the last committed offset vector from the offsets cache.
- In case coordinator was just started or if it just became the coordinator for a new set of consumer groups (by becoming a leader for a partition of the offsets topic),
- it may need to load the offsets topic partition into the cache. In this case, the offset fetch will fail with an
- CoordinatorLoadInProgressException and the consumer may retry the OffsetFetchRequest after backing off.
- </p>
-
-</script>
-
-<div class="p-implementation"></div>
diff --git a/docs/documentation/index.html b/docs/implementation/_index.md
similarity index 85%
copy from docs/documentation/index.html
copy to docs/implementation/_index.md
index 1d7507f30a9..378a674b1f8 100644
--- a/docs/documentation/index.html
+++ b/docs/implementation/_index.md
@@ -1,3 +1,13 @@
+---
+title: Implementation
+description:
+weight: 5
+tags: ['kafka', 'docs', 'implementation']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,4 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
diff --git a/docs/implementation/distribution.md b/docs/implementation/distribution.md
new file mode 100644
index 00000000000..b143961de0a
--- /dev/null
+++ b/docs/implementation/distribution.md
@@ -0,0 +1,35 @@
+---
+title: Distribution
+description: Distribution
+weight: 5
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+## Consumer Offset Tracking
+
+Kafka consumer tracks the maximum offset it has consumed in each partition and has the capability to commit offsets so that it can resume from those offsets in the event of a restart. Kafka provides the option to store all the offsets for a given consumer group in a designated broker (for that group) called the group coordinator. i.e., any consumer instance in that consumer group should send its offset commits and fetches to that group coordinator (broker). Consumer groups are assigned t [...]
+
+When the group coordinator receives an OffsetCommitRequest, it appends the request to a special compacted Kafka topic named ___consumer_offsets_. The broker sends a successful offset commit response to the consumer only after all the replicas of the offsets topic receive the offsets. In case the offsets fail to replicate within a configurable timeout, the offset commit will fail and the consumer may retry the commit after backing off. The brokers periodically compact the offsets topic si [...]
+
+When the coordinator receives an offset fetch request, it simply returns the last committed offset vector from the offsets cache. In case coordinator was just started or if it just became the coordinator for a new set of consumer groups (by becoming a leader for a partition of the offsets topic), it may need to load the offsets topic partition into the cache. In this case, the offset fetch will fail with an CoordinatorLoadInProgressException and the consumer may retry the OffsetFetchRequ [...]
diff --git a/docs/implementation/log.md b/docs/implementation/log.md
new file mode 100644
index 00000000000..6b610ef1f33
--- /dev/null
+++ b/docs/implementation/log.md
@@ -0,0 +1,77 @@
+---
+title: Log
+description: Log
+weight: 4
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+A log for a topic named "my-topic" with two partitions consists of two directories (namely `my-topic-0` and `my-topic-1`) populated with data files containing the messages for that topic. The format of the log files is a sequence of "log entries"; each log entry is a 4 byte integer _N_ storing the message length which is followed by the _N_ message bytes. Each message is uniquely identified by a 64-bit integer _offset_ giving the byte position of the start of this message in the stream o [...]
+
+The exact binary format for records is versioned and maintained as a standard interface so record batches can be transferred between producer, broker, and client without recopying or conversion when desirable. The previous section included details about the on-disk format of records.
+
+The use of the message offset as the message id is unusual. Our original idea was to use a GUID generated by the producer, and maintain a mapping from GUID to offset on each broker. But since a consumer must maintain an ID for each server, the global uniqueness of the GUID provides no value. Furthermore, the complexity of maintaining the mapping from a random id to an offset requires a heavy weight index structure which must be synchronized with disk, essentially requiring a full persist [...]
+
+
+
+## Writes
+
+The log allows serial appends which always go to the last file. This file is rolled over to a fresh file when it reaches a configurable size (say 1GB). The log takes two configuration parameters: _M_ , which gives the number of messages to write before forcing the OS to flush the file to disk, and _S_ , which gives a number of seconds after which a flush is forced. This gives a durability guarantee of losing at most _M_ messages or _S_ seconds of data in the event of a system crash.
+
+## Reads
+
+Reads are done by giving the 64-bit logical offset of a message and an _S_ -byte max chunk size. This will return an iterator over the messages contained in the _S_ -byte buffer. _S_ is intended to be larger than any single message, but in the event of an abnormally large message, the read can be retried multiple times, each time doubling the buffer size, until the message is read successfully. A maximum message and buffer size can be specified to make the server reject messages larger t [...]
+
+The actual process of reading from an offset requires first locating the log segment file in which the data is stored, calculating the file-specific offset from the global offset value, and then reading from that file offset. The search is done as a simple binary search variation against an in-memory range maintained for each file.
+
+The log provides the capability of getting the most recently written message to allow clients to start subscribing as of "right now". This is also useful in the case the consumer fails to consume its data within its SLA-specified number of days. In this case when the client attempts to consume a non-existent offset it is given an OutOfRangeException and can either reset itself or fail as appropriate to the use case.
+
+The following is the format of the results sent to the consumer.
+
+
+ MessageSetSend (fetch result)
+
+ total length : 4 bytes
+ error code : 2 bytes
+ message 1 : x bytes
+ ...
+ message n : x bytes
+
+
+ MultiMessageSetSend (multiFetch result)
+
+ total length : 4 bytes
+ error code : 2 bytes
+ messageSetSend 1
+ ...
+ messageSetSend n
+
+## Deletes
+
+Data is deleted one log segment at a time. The log manager applies two metrics to identify segments which are eligible for deletion: time and size. For time-based policies, the record timestamps are considered, with the largest timestamp in a segment file (order of records is not relevant) defining the retention time for the entire segment. Size-based retention is disabled by default. When enabled the log manager keeps deleting the oldest segment file until the overall size of the partit [...]
+
+## Guarantees
+
+The log provides a configuration parameter _M_ which controls the maximum number of messages that are written before forcing a flush to disk. On startup a log recovery process is run that iterates over all messages in the newest log segment and verifies that each message entry is valid. A message entry is valid if the sum of its size and offset are less than the length of the file AND the CRC32 of the message payload matches the CRC stored with the message. In the event corruption is det [...]
+
+Note that two kinds of corruption must be handled: truncation in which an unwritten block is lost due to a crash, and corruption in which a nonsense block is ADDED to the file. The reason for this is that in general the OS makes no guarantee of the write order between the file inode and the actual block data so in addition to losing written data the file can gain nonsense data if the inode is updated with a new size but a crash occurs before the block containing that data is written. The [...]
diff --git a/docs/implementation/message-format.md b/docs/implementation/message-format.md
new file mode 100644
index 00000000000..d93cc025b32
--- /dev/null
+++ b/docs/implementation/message-format.md
@@ -0,0 +1,115 @@
+---
+title: Message Format
+description: Message Format
+weight: 3
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Messages (aka Records) are always written in batches. The technical term for a batch of messages is a record batch, and a record batch contains one or more records. In the degenerate case, we could have a record batch containing a single record. Record batches and records have their own headers. The format of each is described below.
+
+## Record Batch
+
+The following is the on-disk format of a RecordBatch.
+
+
+ baseOffset: int64
+ batchLength: int32
+ partitionLeaderEpoch: int32
+ magic: int8 (current magic value is 2)
+ crc: uint32
+ attributes: int16
+ bit 0~2:
+ 0: no compression
+ 1: gzip
+ 2: snappy
+ 3: lz4
+ 4: zstd
+ bit 3: timestampType
+ bit 4: isTransactional (0 means not transactional)
+ bit 5: isControlBatch (0 means not a control batch)
+ bit 6: hasDeleteHorizonMs (0 means baseTimestamp is not set as the delete horizon for compaction)
+ bit 7~15: unused
+ lastOffsetDelta: int32
+ baseTimestamp: int64
+ maxTimestamp: int64
+ producerId: int64
+ producerEpoch: int16
+ baseSequence: int32
+ recordsCount: int32
+ records: [Record]
+
+Note that when compression is enabled, the compressed record data is serialized directly following the count of the number of records.
+
+batchLength represents the number of bytes from the current position (immediately after the batchLength field) to the end of the batch. In other words, the total size of a record batch on disk is batchLength + 12 bytes, which includes the 8-byte baseOffset and the 4-byte batchLength field itself.
+
+The CRC covers the data from the attributes to the end of the batch (i.e. all the bytes that follow the CRC). It is located after the magic byte, which means that clients must parse the magic byte before deciding how to interpret the bytes between the batch length and the magic byte. The partition leader epoch field is not included in the CRC computation to avoid the need to recompute the CRC when this field is assigned for every batch that is received by the broker. The CRC-32C (Castagn [...]
+
+On compaction, we preserve the first and last offset/sequence numbers from the original batch when the log is cleaned. This is required in order to be able to restore the producer's state when the log is reloaded. If we did not retain the last sequence number, for example, then after a partition leader failure, the producer might see an OutOfSequence error. The base sequence number must be preserved for duplicate checking (the broker checks incoming Produce requests for duplicates by ver [...]
+
+Compaction may also modify the baseTimestamp if the record batch contains records with a null payload or aborted transaction markers. The baseTimestamp will be set to the timestamp of when those records should be deleted with the delete horizon attribute bit also set.
+
+### Control Batches
+
+A control batch contains a single record called the control record. Control records should not be passed on to applications. Instead, they are used by consumers to filter out aborted transactional messages.
+
+The key of a control record conforms to the following schema:
+
+
+ version: int16 (current version is 0)
+ type: int16 (0 indicates an abort marker, 1 indicates a commit)
+
+The schema for the value of a control record is dependent on the type. The value is opaque to clients.
+
+## Record
+
+The on-disk format of each record is delineated below.
+
+
+ length: varint
+ attributes: int8
+ bit 0~7: unused
+ timestampDelta: varlong
+ offsetDelta: varint
+ keyLength: varint
+ key: byte[]
+ valueLength: varint
+ value: byte[]
+ headersCount: varint
+ Headers => [Header]
+
+### Record Header
+
+
+ headerKeyLength: varint
+ headerKey: String
+ headerValueLength: varint
+ Value: byte[]
+
+The key of a record header is guaranteed to be non-null, while the value of a record header may be null. The order of headers in a record is preserved when producing and consuming.
+
+We use the same varint encoding as Protobuf. More information on the latter can be found [here](https://developers.google.com/protocol-buffers/docs/encoding#varints). The count of headers in a record is also encoded as a varint.
+
+## Old Message Format
+
+Prior to Kafka 0.11, messages were transferred and stored in _message sets_. See [Old Message Format](https://kafka.apache.org/39/documentation/#messageset) for more details.
diff --git a/docs/implementation/messages.md b/docs/implementation/messages.md
new file mode 100644
index 00000000000..487abf22a84
--- /dev/null
+++ b/docs/implementation/messages.md
@@ -0,0 +1,29 @@
+---
+title: Messages
+description: Messages
+weight: 2
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Messages consist of a variable-length header, a variable-length opaque key byte array and a variable-length opaque value byte array. The format of the header is described in the following section. Leaving the key and value opaque is the right decision: there is a great deal of progress being made on serialization libraries right now, and any particular choice is unlikely to be right for all uses. Needless to say a particular application using Kafka would likely mandate a particular seria [...]
diff --git a/docs/implementation/network-layer.md b/docs/implementation/network-layer.md
new file mode 100644
index 00000000000..2d74d79e736
--- /dev/null
+++ b/docs/implementation/network-layer.md
@@ -0,0 +1,29 @@
+---
+title: Network Layer
+description: Network Layer
+weight: 1
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+The network layer is a fairly straight-forward NIO server, and will not be described in great detail. The sendfile implementation is done by giving the `TransferableRecords` interface a `writeTo` method. This allows the file-backed message set to use the more efficient `transferTo` implementation instead of an in-process buffered write. The threading model is a single acceptor thread and _N_ processor threads which handle a fixed number of connections each. This design has been pretty th [...]
diff --git a/docs/introduction.html b/docs/introduction.html
deleted file mode 100644
index 5e1597f725a..00000000000
--- a/docs/introduction.html
+++ /dev/null
@@ -1,220 +0,0 @@
-<!--
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<script><!--#include virtual="js/templateData.js" --></script>
-
-<script id="introduction-template" type="text/x-handlebars-template">
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_streaming" href="#intro_streaming"></a>
- <a href="#intro_streaming">What is event streaming?</a>
- </h4>
- <p>
- Event streaming is the digital equivalent of the human body's central nervous system. It is the
- technological foundation for the 'always-on' world where businesses are increasingly software-defined
- and automated, and where the user of software is more software.
- </p>
- <p>
- Technically speaking, event streaming is the practice of capturing data in real-time from event sources
- like databases, sensors, mobile devices, cloud services, and software applications in the form of streams
- of events; storing these event streams durably for later retrieval; manipulating, processing, and reacting
- to the event streams in real-time as well as retrospectively; and routing the event streams to different
- destination technologies as needed. Event streaming thus ensures a continuous flow and interpretation of
- data so that the right information is at the right place, at the right time.
- </p>
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_usage" href="#intro_usage"></a>
- <a href="#intro_usage">What can I use event streaming for?</a>
- </h4>
- <p>
- Event streaming is applied to a <a href="/powered-by">wide variety of use cases</a>
- across a plethora of industries and organizations. Its many examples include:
- </p>
- <ul>
- <li>
- To process payments and financial transactions in real-time, such as in stock exchanges, banks, and insurances.
- </li>
- <li>
- To track and monitor cars, trucks, fleets, and shipments in real-time, such as in logistics and the automotive industry.
- </li>
- <li>
- To continuously capture and analyze sensor data from IoT devices or other equipment, such as in factories and wind parks.
- </li>
- <li>
- To collect and immediately react to customer interactions and orders, such as in retail, the hotel and travel industry, and mobile applications.
- </li>
- <li>
- To monitor patients in hospital care and predict changes in condition to ensure timely treatment in emergencies.
- </li>
- <li>
- To connect, store, and make available data produced by different divisions of a company.
- </li>
- <li>
- To serve as the foundation for data platforms, event-driven architectures, and microservices.
- </li>
- </ul>
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_platform" href="#intro_platform"></a>
- <a href="#intro_platform">Apache Kafka® is an event streaming platform. What does that mean?</a>
- </h4>
- <p>
- Kafka combines three key capabilities so you can implement
- <a href="/powered-by">your use cases</a>
- for event streaming end-to-end with a single battle-tested solution:
- </p>
- <ol>
- <li>
- To <strong>publish</strong> (write) and <strong>subscribe to</strong> (read) streams of events, including continuous import/export of
- your data from other systems.
- </li>
- <li>
- To <strong>store</strong> streams of events durably and reliably for as long as you want.
- </li>
- <li>
- To <strong>process</strong> streams of events as they occur or retrospectively.
- </li>
- </ol>
- <p>
- And all this functionality is provided in a distributed, highly scalable, elastic, fault-tolerant, and
- secure manner. Kafka can be deployed on bare-metal hardware, virtual machines, and containers, and on-premises
- as well as in the cloud. You can choose between self-managing your Kafka environments and using fully managed
- services offered by a variety of vendors.
- </p>
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_nutshell" href="#intro_nutshell"></a>
- <a href="#intro_nutshell">How does Kafka work in a nutshell?</a>
- </h4>
- <p>
- Kafka is a distributed system consisting of <strong>servers</strong> and <strong>clients</strong> that
- communicate via a high-performance <a href="/protocol.html">TCP network protocol</a>.
- It can be deployed on bare-metal hardware, virtual machines, and containers in on-premise as well as cloud
- environments.
- </p>
- <p>
- <strong>Servers</strong>: Kafka is run as a cluster of one or more servers that can span multiple datacenters
- or cloud regions. Some of these servers form the storage layer, called the brokers. Other servers run
- <a href="/documentation/#connect">Kafka Connect</a> to continuously import and export
- data as event streams to integrate Kafka with your existing systems such as relational databases as well as
- other Kafka clusters. To let you implement mission-critical use cases, a Kafka cluster is highly scalable
- and fault-tolerant: if any of its servers fails, the other servers will take over their work to ensure
- continuous operations without any data loss.
- </p>
- <p>
- <strong>Clients</strong>: They allow you to write distributed applications and microservices that read, write,
- and process streams of events in parallel, at scale, and in a fault-tolerant manner even in the case of network
- problems or machine failures. Kafka ships with some such clients included, which are augmented by
- <a href="https://cwiki.apache.org/confluence/x/3gDVAQ">dozens of clients</a> provided by the Kafka
- community: clients are available for Java and Scala including the higher-level
- <a href="/documentation/streams/">Kafka Streams</a> library, for Go, Python, C/C++, and
- many other programming languages as well as REST APIs.
- </p>
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_concepts_and_terms" href="#intro_concepts_and_terms"></a>
- <a href="#intro_concepts_and_terms">Main Concepts and Terminology</a>
- </h4>
- <p>
- An <strong>event</strong> records the fact that "something happened" in the world or in your business. It is also called record or message in the documentation. When you read or write data to Kafka, you do this in the form of events. Conceptually, an event has a key, value, timestamp, and optional metadata headers. Here's an example event:
- </p>
- <ul>
- <li>
- Event key: "Alice"
- </li>
- <li>
- Event value: "Made a payment of $200 to Bob"
- </li>
- <li>
- Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
- </li>
- </ul>
- <p>
- <strong>Producers</strong> are those client applications that publish (write) events to Kafka, and <strong>consumers</strong> are those that subscribe to (read and process) these events. In Kafka, producers and consumers are fully decoupled and agnostic of each other, which is a key design element to achieve the high scalability that Kafka is known for. For example, producers never need to wait for consumers. Kafka provides various <a href="/documentation/#semantics">guarantees</a> s [...]
- </p>
- <p>
- Events are organized and durably stored in <strong>topics</strong>. Very simplified, a topic is similar to a folder in a filesystem, and the events are the files in that folder. An example topic name could be "payments". Topics in Kafka are always multi-producer and multi-subscriber: a topic can have zero, one, or many producers that write events to it, as well as zero, one, or many consumers that subscribe to these events. Events in a topic can be read as often as needed—unlike trad [...]
- </p>
- <p>
- Topics are <strong>partitioned</strong>, meaning a topic is spread over a number of "buckets" located on different Kafka brokers. This distributed placement of your data is very important for scalability because it allows client applications to both read and write the data from/to many brokers at the same time. When a new event is published to a topic, it is actually appended to one of the topic's partitions. Events with the same event key (e.g., a customer or vehicle ID) are written [...]
- </p>
- <figure class="figure">
- <img src="/images/streams-and-tables-p1_p4.png" class="figure-image" />
- <figcaption class="figure-caption">
- Figure: This example topic has four partitions P1–P4. Two different producer clients are publishing,
- independently from each other, new events to the topic by writing events over the network to the topic's
- partitions. Events with the same key (denoted by their color in the figure) are written to the same
- partition. Note that both producers can write to the same partition if appropriate.
- </figcaption>
- </figure>
- <p>
- To make your data fault-tolerant and highly-available, every topic can be <strong>replicated</strong>, even across geo-regions or datacenters, so that there are always multiple brokers that have a copy of the data just in case things go wrong, you want to do maintenance on the brokers, and so on. A common production setting is a replication factor of 3, i.e., there will always be three copies of your data. This replication is performed at the level of topic-partitions.
- </p>
- <p>
- This primer should be sufficient for an introduction. The <a href="/documentation/#design">Design</a> section of the documentation explains Kafka's various concepts in full detail, if you are interested.
- </p>
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_apis" href="#intro_apis"></a>
- <a href="#intro_apis">Kafka APIs</a>
- </h4>
- <p>
- In addition to command line tooling for management and administration tasks, Kafka has five core APIs for Java and Scala:
- </p>
- <ul>
- <li>
- The <a href="/documentation.html#adminapi">Admin API</a> to manage and inspect topics, brokers, and other Kafka objects.
- </li>
- <li>
- The <a href="/documentation.html#producerapi">Producer API</a> to publish (write) a stream of events to one or more Kafka topics.
- </li>
- <li>
- The <a href="/documentation.html#consumerapi">Consumer API</a> to subscribe to (read) one or more topics and to process the stream of events produced to them.
- </li>
- <li>
- The <a href="/documentation/streams">Kafka Streams API</a> to implement stream processing applications and microservices. It provides higher-level functions to process event streams, including transformations, stateful operations like aggregations and joins, windowing, processing based on event-time, and more. Input is read from one or more topics in order to generate output to one or more topics, effectively transforming the input streams to output streams.
- </li>
- <li>
- The <a href="/documentation.html#connect">Kafka Connect API</a> to build and run reusable data import/export connectors that consume (read) or produce (write) streams of events from and to external systems and applications so they can integrate with Kafka. For example, a connector to a relational database like PostgreSQL might capture every change to a set of tables. However, in practice, you typically don't need to implement your own connectors because the Kafka community already [...]
- </li>
- </ul>
-
- <!-- TODO: add new section once supporting page is written -->
-
- <h4 class="anchor-heading">
- <a class="anchor-link" id="intro_more" href="#intro_more"></a>
- <a href="#intro_more">Where to go from here</a>
- </h4>
- <ul>
- <li>
- To get hands-on experience with Kafka, follow the <a href="/quickstart">Quickstart</a>.
- </li>
- <li>
- To understand Kafka in more detail, read the <a href="/documentation/">Documentation</a>.
- You also have your choice of <a href="/books-and-papers">Kafka books and academic papers</a>.
- </li>
- <li>
- Browse through the <a href="/powered-by">Use Cases</a> to learn how other users in our world-wide community are getting value out of Kafka.
- </li>
- <li>
- Join a <a href="/events">local Kafka meetup group</a> and
- <a href="https://kafka-summit.org/past-events/">watch talks from Kafka Summit</a>, the main conference of the Kafka community.
- </li>
- </ul>
-</script>
-
-<div class="p-introduction"></div>
diff --git a/docs/js/templateData.js b/docs/js/templateData.js
deleted file mode 100644
index 5ab87d9f7c5..00000000000
--- a/docs/js/templateData.js
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-*/
-
-// Define variables for doc templates
-var context={
- "version": "42",
- "dotVersion": "4.2",
- "fullDotVersion": "4.2.0",
- "scalaVersion": "2.13"
-};
diff --git a/docs/documentation/streams/architecture.html b/docs/kafka-connect/_index.md
similarity index 86%
rename from docs/documentation/streams/architecture.html
rename to docs/kafka-connect/_index.md
index ad7b323d077..55d6e5325a3 100644
--- a/docs/documentation/streams/architecture.html
+++ b/docs/kafka-connect/_index.md
@@ -1,3 +1,13 @@
+---
+title: Kafka Connect
+description:
+weight: 8
+tags: ['kafka', 'docs', 'connect']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,5 +25,4 @@
limitations under the License.
-->
-<!-- should always link the latest release's documentation -->
-<!--#include virtual="../../streams/architecture.html" -->
+
diff --git a/docs/kafka-connect/administration.md b/docs/kafka-connect/administration.md
new file mode 100644
index 00000000000..742a531742d
--- /dev/null
+++ b/docs/kafka-connect/administration.md
@@ -0,0 +1,76 @@
+---
+title: Administration
+description: Administration
+weight: 4
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Kafka Connect's REST layer provides a set of APIs to enable administration of the cluster. This includes APIs to view the configuration of connectors and the status of their tasks, as well as to alter their current behavior (e.g. changing configuration and restarting tasks).
+
+When a connector is first submitted to the cluster, a rebalance is triggered between the Connect workers in order to distribute the load that consists of the tasks of the new connector. This same rebalancing procedure is also used when connectors increase or decrease the number of tasks they require, when a connector's configuration is changed, or when a worker is added or removed from the group as part of an intentional upgrade of the Connect cluster or due to a failure.
+
+In versions prior to 2.3.0, the Connect workers would rebalance the full set of connectors and their tasks in the cluster as a simple way to make sure that each worker has approximately the same amount of work. This behavior can be still enabled by setting `connect.protocol=eager`.
+
+Starting with 2.3.0, Kafka Connect is using by default a protocol that performs [incremental cooperative rebalancing](https://cwiki.apache.org/confluence/x/Y4MCBg) that incrementally balances the connectors and tasks across the Connect workers, affecting only tasks that are new, to be removed, or need to move from one worker to another. Other tasks are not stopped and restarted during the rebalance, as they would have been with the old protocol.
+
+If a Connect worker leaves the group, intentionally or due to a failure, Connect waits for `scheduled.rebalance.max.delay.ms` before triggering a rebalance. This delay defaults to five minutes (`300000ms`) to tolerate failures or upgrades of workers without immediately redistributing the load of a departing worker. If this worker returns within the configured delay, it gets its previously assigned tasks in full. However, this means that the tasks will remain unassigned until the time spe [...]
+
+The new Connect protocol is enabled when all the workers that form the Connect cluster are configured with `connect.protocol=compatible`, which is also the default value when this property is missing. Therefore, upgrading to the new Connect protocol happens automatically when all the workers upgrade to 2.3.0. A rolling upgrade of the Connect cluster will activate incremental cooperative rebalancing when the last worker joins on version 2.3.0.
+
+You can use the REST API to view the current status of a connector and its tasks, including the ID of the worker to which each was assigned. For example, the `GET /connectors/file-source/status` request shows the status of a connector named `file-source`:
+
+
+ {
+ "name": "file-source",
+ "connector": {
+ "state": "RUNNING",
+ "worker_id": "192.168.1.208:8083"
+ },
+ "tasks": [
+ {
+ "id": 0,
+ "state": "RUNNING",
+ "worker_id": "192.168.1.209:8083"
+ }
+ ]
+ }
+
+Connectors and their tasks publish status updates to a shared topic (configured with `status.storage.topic`) which all workers in the cluster monitor. Because the workers consume this topic asynchronously, there is typically a (short) delay before a state change is visible through the status API. The following states are possible for a connector or one of its tasks:
+
+ * **UNASSIGNED:** The connector/task has not yet been assigned to a worker.
+ * **RUNNING:** The connector/task is running.
+ * **PAUSED:** The connector/task has been administratively paused.
+ * **STOPPED:** The connector has been stopped. Note that this state is not applicable to tasks because the tasks for a stopped connector are shut down and won't be visible in the status API.
+ * **FAILED:** The connector/task has failed (usually by raising an exception, which is reported in the status output).
+ * **RESTARTING:** The connector/task is either actively restarting or is expected to restart soon
+
+
+
+In most cases, connector and task states will match, though they may be different for short periods of time when changes are occurring or if tasks have failed. For example, when a connector is first started, there may be a noticeable delay before the connector and its tasks have all transitioned to the RUNNING state. States will also diverge when tasks fail since Connect does not automatically restart failed tasks. To restart a connector/task manually, you can use the restart APIs listed [...]
+
+Starting with 2.5.0, Kafka Connect uses the `status.storage.topic` to also store information related to the topics that each connector is using. Connect Workers use these per-connector topic status updates to respond to requests to the REST endpoint `GET /connectors/{name}/topics` by returning the set of topic names that a connector is using. A request to the REST endpoint `PUT /connectors/{name}/topics/reset` resets the set of active topics for a connector and allows a new set to be pop [...]
+
+It's sometimes useful to temporarily stop the message processing of a connector. For example, if the remote system is undergoing maintenance, it would be preferable for source connectors to stop polling it for new data instead of filling logs with exception spam. For this use case, Connect offers a pause/resume API. While a source connector is paused, Connect will stop polling it for additional records. While a sink connector is paused, Connect will stop pushing new messages to it. The p [...]
+
+In 3.5.0, Connect introduced a stop API that completely shuts down the tasks for a connector and deallocates any resources claimed by them. This is different from pausing a connector where tasks are left idling and any resources claimed by them are left allocated (which allows the connector to begin processing data quickly once it is resumed). Stopping a connector is more efficient from a resource usage standpoint than pausing it, but can cause it to take longer to begin processing data [...]
diff --git a/docs/kafka-connect/connector-development-guide.md b/docs/kafka-connect/connector-development-guide.md
new file mode 100644
index 00000000000..d8544666e96
--- /dev/null
+++ b/docs/kafka-connect/connector-development-guide.md
@@ -0,0 +1,412 @@
+---
+title: Connector Development Guide
+description: Connector Development Guide
+weight: 3
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+This guide describes how developers can write new connectors for Kafka Connect to move data between Kafka and other systems. It briefly reviews a few key concepts and then describes how to create a simple connector.
+
+## Core Concepts and APIs
+
+### Connectors and Tasks
+
+To copy data between Kafka and another system, users create a `Connector` for the system they want to pull data from or push data to. Connectors come in two flavors: `SourceConnectors` import data from another system (e.g. `JDBCSourceConnector` would import a relational database into Kafka) and `SinkConnectors` export data (e.g. `HDFSSinkConnector` would export the contents of a Kafka topic to an HDFS file).
+
+`Connectors` do not perform any data copying themselves: their configuration describes the data to be copied, and the `Connector` is responsible for breaking that job into a set of `Tasks` that can be distributed to workers. These `Tasks` also come in two corresponding flavors: `SourceTask` and `SinkTask`.
+
+With an assignment in hand, each `Task` must copy its subset of the data to or from Kafka. In Kafka Connect, it should always be possible to frame these assignments as a set of input and output streams consisting of records with consistent schemas. Sometimes this mapping is obvious: each file in a set of log files can be considered a stream with each parsed line forming a record using the same schema and offsets stored as byte offsets in the file. In other cases it may require more effor [...]
+
+### Streams and Records
+
+Each stream should be a sequence of key-value records. Both the keys and values can have complex structure -- many primitive types are provided, but arrays, objects, and nested data structures can be represented as well. The runtime data format does not assume any particular serialization format; this conversion is handled internally by the framework.
+
+In addition to the key and value, records (both those generated by sources and those delivered to sinks) have associated stream IDs and offsets. These are used by the framework to periodically commit the offsets of data that have been processed so that in the event of failures, processing can resume from the last committed offsets, avoiding unnecessary reprocessing and duplication of events.
+
+### Dynamic Connectors
+
+Not all jobs are static, so `Connector` implementations are also responsible for monitoring the external system for any changes that might require reconfiguration. For example, in the `JDBCSourceConnector` example, the `Connector` might assign a set of tables to each `Task`. When a new table is created, it must discover this so it can assign the new table to one of the `Tasks` by updating its configuration. When it notices a change that requires reconfiguration (or a change in the number [...]
+
+## Developing a Simple Connector
+
+Developing a connector only requires implementing two interfaces, the `Connector` and `Task`. A simple example is included with the source code for Kafka in the `file` package. This connector is meant for use in standalone mode and has implementations of a `SourceConnector`/`SourceTask` to read each line of a file and emit it as a record and a `SinkConnector`/`SinkTask` that writes each record to a file.
+
+The rest of this section will walk through some code to demonstrate the key steps in creating a connector, but developers should also refer to the full example source code as many details are omitted for brevity.
+
+### Connector Example
+
+We'll cover the `SourceConnector` as a simple example. `SinkConnector` implementations are very similar. Pick a package and class name, these examples will use the `FileStreamSourceConnector` but substitute your own class name where appropriate. In order to make the plugin discoverable at runtime, add a ServiceLoader manifest to your resources in `META-INF/services/org.apache.kafka.connect.source.SourceConnector` with your fully-qualified class name on a single line:
+
+
+ com.example.FileStreamSourceConnector
+
+Create a class that inherits from `SourceConnector` and add a field that will store the configuration information to be propagated to the task(s) (the topic to send data to, and optionally - the filename to read from and the maximum batch size):
+
+
+ package com.example;
+
+ public class FileStreamSourceConnector extends SourceConnector {
+ private Map<String, String> props;
+
+The easiest method to fill in is `taskClass()`, which defines the class that should be instantiated in worker processes to actually read the data:
+
+
+ @Override
+ public Class<? extends Task> taskClass() {
+ return FileStreamSourceTask.class;
+ }
+
+We will define the `FileStreamSourceTask` class below. Next, we add some standard lifecycle methods, `start()` and `stop()`:
+
+
+ @Override
+ public void start(Map<String, String> props) {
+ // Initialization logic and setting up of resources can take place in this method.
+ // This connector doesn't need to do any of that, but we do log a helpful message to the user.
+
+ this.props = props;
+ AbstractConfig config = new AbstractConfig(CONFIG_DEF, props);
+ String filename = config.getString(FILE_CONFIG);
+ filename = (filename == null || filename.isEmpty()) ? "standard input" : config.getString(FILE_CONFIG);
+ log.info("Starting file source connector reading from {}", filename);
+ }
+
+ @Override
+ public void stop() {
+ // Nothing to do since no background monitoring is required.
+ }
+
+Finally, the real core of the implementation is in `taskConfigs()`. In this case we are only handling a single file, so even though we may be permitted to generate more tasks as per the `maxTasks` argument, we return a list with only one entry:
+
+
+ @Override
+ public List<Map<String, String>> taskConfigs(int maxTasks) {
+ // Note that the task configs could contain configs additional to or different from the connector configs if needed. For instance,
+ // if different tasks have different responsibilities, or if different tasks are meant to process different subsets of the source data stream).
+ ArrayList<Map<String, String>> configs = new ArrayList<>();
+ // Only one input stream makes sense.
+ configs.add(props);
+ return configs;
+ }
+
+Even with multiple tasks, this method implementation is usually pretty simple. It just has to determine the number of input tasks, which may require contacting the remote service it is pulling data from, and then divvy them up. Because some patterns for splitting work among tasks are so common, some utilities are provided in `ConnectorUtils` to simplify these cases.
+
+Note that this simple example does not include dynamic input. See the discussion in the next section for how to trigger updates to task configs.
+
+### Task Example - Source Task
+
+Next we'll describe the implementation of the corresponding `SourceTask`. The implementation is short, but too long to cover completely in this guide. We'll use pseudo-code to describe most of the implementation, but you can refer to the source code for the full example.
+
+Just as with the connector, we need to create a class inheriting from the appropriate base `Task` class. It also has some standard lifecycle methods:
+
+
+ public class FileStreamSourceTask extends SourceTask {
+ private String filename;
+ private InputStream stream;
+ private String topic;
+ private int batchSize;
+
+ @Override
+ public void start(Map<String, String> props) {
+ filename = props.get(FileStreamSourceConnector.FILE_CONFIG);
+ stream = openOrThrowError(filename);
+ topic = props.get(FileStreamSourceConnector.TOPIC_CONFIG);
+ batchSize = props.get(FileStreamSourceConnector.TASK_BATCH_SIZE_CONFIG);
+ }
+
+ @Override
+ public synchronized void stop() {
+ stream.close();
+ }
+ }
+
+These are slightly simplified versions, but show that these methods should be relatively simple and the only work they should perform is allocating or freeing resources. There are two points to note about this implementation. First, the `start()` method does not yet handle resuming from a previous offset, which will be addressed in a later section. Second, the `stop()` method is synchronized. This will be necessary because `SourceTasks` are given a dedicated thread which they can block i [...]
+
+Next, we implement the main functionality of the task, the `poll()` method which gets events from the input system and returns a `List<SourceRecord>`:
+
+
+ @Override
+ public List<SourceRecord> poll() throws InterruptedException {
+ try {
+ ArrayList<SourceRecord> records = new ArrayList<>();
+ while (streamValid(stream) && records.isEmpty()) {
+ LineAndOffset line = readToNextLine(stream);
+ if (line != null) {
+ Map<String, Object> sourcePartition = Collections.singletonMap("filename", filename);
+ Map<String, Object> sourceOffset = Collections.singletonMap("position", streamOffset);
+ records.add(new SourceRecord(sourcePartition, sourceOffset, topic, Schema.STRING_SCHEMA, line));
+ if (records.size() >= batchSize) {
+ return records;
+ }
+ } else {
+ Thread.sleep(1);
+ }
+ }
+ return records;
+ } catch (IOException e) {
+ // Underlying stream was killed, probably as a result of calling stop. Allow to return
+ // null, and driving thread will handle any shutdown if necessary.
+ }
+ return null;
+ }
+
+Again, we've omitted some details, but we can see the important steps: the `poll()` method is going to be called repeatedly, and for each call it will loop trying to read records from the file. For each line it reads, it also tracks the file offset. It uses this information to create an output `SourceRecord` with four pieces of information: the source partition (there is only one, the single file being read), source offset (byte offset in the file), output topic name, and output value (t [...]
+
+Note that this implementation uses the normal Java `InputStream` interface and may sleep if data is not available. This is acceptable because Kafka Connect provides each task with a dedicated thread. While task implementations have to conform to the basic `poll()` interface, they have a lot of flexibility in how they are implemented. In this case, an NIO-based implementation would be more efficient, but this simple approach works, is quick to implement, and is compatible with older versi [...]
+
+Although not used in the example, `SourceTask` also provides two APIs to commit offsets in the source system: `commit` and `commitRecord`. The APIs are provided for source systems which have an acknowledgement mechanism for messages. Overriding these methods allows the source connector to acknowledge messages in the source system, either in bulk or individually, once they have been written to Kafka. The `commit` API stores the offsets in the source system, up to the offsets that have bee [...]
+
+### Sink Tasks
+
+The previous section described how to implement a simple `SourceTask`. Unlike `SourceConnector` and `SinkConnector`, `SourceTask` and `SinkTask` have very different interfaces because `SourceTask` uses a pull interface and `SinkTask` uses a push interface. Both share the common lifecycle methods, but the `SinkTask` interface is quite different:
+
+
+ public abstract class SinkTask implements Task {
+ public void initialize(SinkTaskContext context) {
+ this.context = context;
+ }
+
+ public abstract void put(Collection<SinkRecord> records);
+
+ public void flush(Map<TopicPartition, OffsetAndMetadata> currentOffsets) {
+ }
+ }
+
+The `SinkTask` documentation contains full details, but this interface is nearly as simple as the `SourceTask`. The `put()` method should contain most of the implementation, accepting sets of `SinkRecords`, performing any required translation, and storing them in the destination system. This method does not need to ensure the data has been fully written to the destination system before returning. In fact, in many cases internal buffering will be useful so an entire batch of records can b [...]
+
+The `flush()` method is used during the offset commit process, which allows tasks to recover from failures and resume from a safe point such that no events will be missed. The method should push any outstanding data to the destination system and then block until the write has been acknowledged. The `offsets` parameter can often be ignored, but is useful in some cases where implementations want to store offset information in the destination store to provide exactly-once delivery. For exam [...]
+
+### Errant Record Reporter
+
+When error reporting is enabled for a connector, the connector can use an `ErrantRecordReporter` to report problems with individual records sent to a sink connector. The following example shows how a connector's `SinkTask` subclass might obtain and use the `ErrantRecordReporter`, safely handling a null reporter when the DLQ is not enabled or when the connector is installed in an older Connect runtime that doesn't have this reporter feature:
+
+
+ private ErrantRecordReporter reporter;
+
+ @Override
+ public void start(Map<String, String> props) {
+ ...
+ try {
+ reporter = context.errantRecordReporter(); // may be null if DLQ not enabled
+ } catch (NoSuchMethodException | NoClassDefFoundError e) {
+ // Will occur in Connect runtimes earlier than 2.6
+ reporter = null;
+ }
+ }
+
+ @Override
+ public void put(Collection<SinkRecord> records) {
+ for (SinkRecord record: records) {
+ try {
+ // attempt to process and send record to data sink
+ process(record);
+ } catch(Exception e) {
+ if (reporter != null) {
+ // Send errant record to error reporter
+ reporter.report(record, e);
+ } else {
+ // There's no error reporter, so fail
+ throw new ConnectException("Failed on record", e);
+ }
+ }
+ }
+ }
+
+### Resuming from Previous Offsets
+
+The `SourceTask` implementation included a stream ID (the input filename) and offset (position in the file) with each record. The framework uses this to commit offsets periodically so that in the case of a failure, the task can recover and minimize the number of events that are reprocessed and possibly duplicated (or to resume from the most recent offset if Kafka Connect was stopped gracefully, e.g. in standalone mode or due to a job reconfiguration). This commit process is completely au [...]
+
+To correctly resume upon startup, the task can use the `SourceContext` passed into its `initialize()` method to access the offset data. In `initialize()`, we would add a bit more code to read the offset (if it exists) and seek to that position:
+
+
+ stream = new FileInputStream(filename);
+ Map<String, Object> offset = context.offsetStorageReader().offset(Collections.singletonMap(FILENAME_FIELD, filename));
+ if (offset != null) {
+ Long lastRecordedOffset = (Long) offset.get("position");
+ if (lastRecordedOffset != null)
+ seekToOffset(stream, lastRecordedOffset);
+ }
+
+Of course, you might need to read many keys for each of the input streams. The `OffsetStorageReader` interface also allows you to issue bulk reads to efficiently load all offsets, then apply them by seeking each input stream to the appropriate position.
+
+### Exactly-once source connectors
+
+#### Supporting exactly-once
+
+With the passing of [KIP-618](https://cwiki.apache.org/confluence/x/Vg0rCQ), Kafka Connect supports exactly-once source connectors as of version 3.3.0. In order for a source connector to take advantage of this support, it must be able to provide meaningful source offsets for each record that it emits, and resume consumption from the external system at the exact position corresponding to any of those offsets without dropping or duplicating messages.
+
+#### Defining transaction boundaries
+
+By default, the Kafka Connect framework will create and commit a new Kafka transaction for each batch of records that a source task returns from its `poll` method. However, connectors can also define their own transaction boundaries, which can be enabled by users by setting the `transaction.boundary` property to `connector` in the config for the connector.
+
+If enabled, the connector's tasks will have access to a `TransactionContext` from their `SourceTaskContext`, which they can use to control when transactions are aborted and committed.
+
+For example, to commit a transaction at least every ten records:
+
+
+ private int recordsSent;
+
+ @Override
+ public void start(Map<String, String> props) {
+ this.recordsSent = 0;
+ }
+
+ @Override
+ public List<SourceRecord> poll() {
+ List<SourceRecord> records = fetchRecords();
+ boolean shouldCommit = false;
+ for (SourceRecord record : records) {
+ if (++this.recordsSent >= 10) {
+ shouldCommit = true;
+ }
+ }
+ if (shouldCommit) {
+ this.recordsSent = 0;
+ this.context.transactionContext().commitTransaction();
+ }
+ return records;
+ }
+
+Or to commit a transaction for exactly every tenth record:
+
+
+ private int recordsSent;
+
+ @Override
+ public void start(Map<String, String> props) {
+ this.recordsSent = 0;
+ }
+
+ @Override
+ public List<SourceRecord> poll() {
+ List<SourceRecord> records = fetchRecords();
+ for (SourceRecord record : records) {
+ if (++this.recordsSent % 10 == 0) {
+ this.context.transactionContext().commitTransaction(record);
+ }
+ }
+ return records;
+ }
+
+Most connectors do not need to define their own transaction boundaries. However, it may be useful if files or objects in the source system are broken up into multiple source records, but should be delivered atomically. Additionally, it may be useful if it is impossible to give each source record a unique source offset, if every record with a given offset is delivered within a single transaction.
+
+Note that if the user has not enabled connector-defined transaction boundaries in the connector configuration, the `TransactionContext` returned by `context.transactionContext()` will be `null`.
+
+#### Validation APIs
+
+A few additional preflight validation APIs can be implemented by source connector developers.
+
+Some users may require exactly-once semantics from a connector. In this case, they may set the `exactly.once.support` property to `required` in the configuration for the connector. When this happens, the Kafka Connect framework will ask the connector whether it can provide exactly-once semantics with the specified configuration. This is done by invoking the `exactlyOnceSupport` method on the connector.
+
+If a connector doesn't support exactly-once semantics, it should still implement this method to let users know for certain that it cannot provide exactly-once semantics:
+
+
+ @Override
+ public ExactlyOnceSupport exactlyOnceSupport(Map<String, String> props) {
+ // This connector cannot provide exactly-once semantics under any conditions
+ return ExactlyOnceSupport.UNSUPPORTED;
+ }
+
+
+Otherwise, a connector should examine the configuration, and return `ExactlyOnceSupport.SUPPORTED` if it can provide exactly-once semantics:
+
+
+ @Override
+ public ExactlyOnceSupport exactlyOnceSupport(Map<String, String> props) {
+ // This connector can always provide exactly-once semantics
+ return ExactlyOnceSupport.SUPPORTED;
+ }
+
+Additionally, if the user has configured the connector to define its own transaction boundaries, the Kafka Connect framework will ask the connector whether it can define its own transaction boundaries with the specified configuration, using the `canDefineTransactionBoundaries` method:
+
+
+ @Override
+ public ConnectorTransactionBoundaries canDefineTransactionBoundaries(Map<String, String> props) {
+ // This connector can always define its own transaction boundaries
+ return ConnectorTransactionBoundaries.SUPPORTED;
+ }
+
+This method should only be implemented for connectors that can define their own transaction boundaries in some cases. If a connector is never able to define its own transaction boundaries, it does not need to implement this method.
+
+## Dynamic Input/Output Streams
+
+Kafka Connect is intended to define bulk data copying jobs, such as copying an entire database rather than creating many jobs to copy each table individually. One consequence of this design is that the set of input or output streams for a connector can vary over time.
+
+Source connectors need to monitor the source system for changes, e.g. table additions/deletions in a database. When they pick up changes, they should notify the framework via the `ConnectorContext` object that reconfiguration is necessary. For example, in a `SourceConnector`:
+
+
+ if (inputsChanged())
+ this.context.requestTaskReconfiguration();
+
+The framework will promptly request new configuration information and update the tasks, allowing them to gracefully commit their progress before reconfiguring them. Note that in the `SourceConnector` this monitoring is currently left up to the connector implementation. If an extra thread is required to perform this monitoring, the connector must allocate it itself.
+
+Ideally this code for monitoring changes would be isolated to the `Connector` and tasks would not need to worry about them. However, changes can also affect tasks, most commonly when one of their input streams is destroyed in the input system, e.g. if a table is dropped from a database. If the `Task` encounters the issue before the `Connector`, which will be common if the `Connector` needs to poll for changes, the `Task` will need to handle the subsequent error. Thankfully, this can usua [...]
+
+`SinkConnectors` usually only have to handle the addition of streams, which may translate to new entries in their outputs (e.g., a new database table). The framework manages any changes to the Kafka input, such as when the set of input topics changes because of a regex subscription. `SinkTasks` should expect new input streams, which may require creating new resources in the downstream system, such as a new table in a database. The trickiest situation to handle in these cases may be confl [...]
+
+## Configuration Validation
+
+Kafka Connect allows you to validate connector configurations before submitting a connector to be executed and can provide feedback about errors and recommended values. To take advantage of this, connector developers need to provide an implementation of `config()` to expose the configuration definition to the framework.
+
+The following code in `FileStreamSourceConnector` defines the configuration and exposes it to the framework.
+
+
+ static final ConfigDef CONFIG_DEF = new ConfigDef()
+ .define(FILE_CONFIG, Type.STRING, null, Importance.HIGH, "Source filename. If not specified, the standard input will be used")
+ .define(TOPIC_CONFIG, Type.STRING, ConfigDef.NO_DEFAULT_VALUE, new ConfigDef.NonEmptyString(), Importance.HIGH, "The topic to publish data to")
+ .define(TASK_BATCH_SIZE_CONFIG, Type.INT, DEFAULT_TASK_BATCH_SIZE, Importance.LOW,
+ "The maximum number of records the source task can read from the file each time it is polled");
+
+ public ConfigDef config() {
+ return CONFIG_DEF;
+ }
+
+`ConfigDef` class is used for specifying the set of expected configurations. For each configuration, you can specify the name, the type, the default value, the documentation, the group information, the order in the group, the width of the configuration value and the name suitable for display in the UI. Plus, you can provide special validation logic used for single configuration validation by overriding the `Validator` class. Moreover, as there may be dependencies between configurations, [...]
+
+Also, the `validate()` method in `Connector` provides a default validation implementation which returns a list of allowed configurations together with configuration errors and recommended values for each configuration. However, it does not use the recommended values for configuration validation. You may provide an override of the default implementation for customized configuration validation, which may use the recommended values.
+
+## Working with Schemas
+
+The FileStream connectors are good examples because they are simple, but they also have trivially structured data -- each line is just a string. Almost all practical connectors will need schemas with more complex data formats.
+
+To create more complex data, you'll need to work with the Kafka Connect `data` API. Most structured records will need to interact with two classes in addition to primitive types: `Schema` and `Struct`.
+
+The API documentation provides a complete reference, but here is a simple example creating a `Schema` and `Struct`:
+
+
+ Schema schema = SchemaBuilder.struct().name(NAME)
+ .field("name", Schema.STRING_SCHEMA)
+ .field("age", Schema.INT_SCHEMA)
+ .field("admin", SchemaBuilder.bool().defaultValue(false).build())
+ .build();
+
+ Struct struct = new Struct(schema)
+ .put("name", "Barbara Liskov")
+ .put("age", 75);
+
+If you are implementing a source connector, you'll need to decide when and how to create schemas. Where possible, you should avoid recomputing them as much as possible. For example, if your connector is guaranteed to have a fixed schema, create it statically and reuse a single instance.
+
+However, many connectors will have dynamic schemas. One simple example of this is a database connector. Considering even just a single table, the schema will not be predefined for the entire connector (as it varies from table to table). But it also may not be fixed for a single table over the lifetime of the connector since the user may execute an `ALTER TABLE` command. The connector must be able to detect these changes and react appropriately.
+
+Sink connectors are usually simpler because they are consuming data and therefore do not need to create schemas. However, they should take just as much care to validate that the schemas they receive have the expected format. When the schema does not match -- usually indicating the upstream producer is generating invalid data that cannot be correctly translated to the destination system -- sink connectors should throw an exception to indicate this error to the system.
diff --git a/docs/kafka-connect/overview.md b/docs/kafka-connect/overview.md
new file mode 100644
index 00000000000..c6969fa17c1
--- /dev/null
+++ b/docs/kafka-connect/overview.md
@@ -0,0 +1,40 @@
+---
+title: Overview
+description: Overview
+weight: 1
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+Kafka Connect is a tool for scalably and reliably streaming data between Apache Kafka and other systems. It makes it simple to quickly define _connectors_ that move large collections of data into and out of Kafka. Kafka Connect can ingest entire databases or collect metrics from all your application servers into Kafka topics, making the data available for stream processing with low latency. An export job can deliver data from Kafka topics into secondary storage and query systems or into [...]
+
+Kafka Connect features include:
+
+ * **A common framework for Kafka connectors** \- Kafka Connect standardizes integration of other data systems with Kafka, simplifying connector development, deployment, and management
+ * **Distributed and standalone modes** \- scale up to a large, centrally managed service supporting an entire organization or scale down to development, testing, and small production deployments
+ * **REST interface** \- submit and manage connectors to your Kafka Connect cluster via an easy to use REST API
+ * **Automatic offset management** \- with just a little information from connectors, Kafka Connect can manage the offset commit process automatically so connector developers do not need to worry about this error prone part of connector development
+ * **Distributed and scalable by default** \- Kafka Connect builds on the existing group management protocol. More workers can be added to scale up a Kafka Connect cluster.
+ * **Streaming/batch integration** \- leveraging Kafka's existing capabilities, Kafka Connect is an ideal solution for bridging streaming and batch data systems
+
+
diff --git a/docs/kafka-connect/user-guide.md b/docs/kafka-connect/user-guide.md
new file mode 100644
index 00000000000..d91c6f47111
--- /dev/null
+++ b/docs/kafka-connect/user-guide.md
@@ -0,0 +1,715 @@
+---
+title: User Guide
+description: User Guide
+weight: 2
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+The [quickstart](../quickstart) provides a brief example of how to run a standalone version of Kafka Connect. This section describes how to configure, run, and manage Kafka Connect in more detail.
+
+## Running Kafka Connect
+
+Kafka Connect currently supports two modes of execution: standalone (single process) and distributed.
+
+In standalone mode all work is performed in a single process. This configuration is simpler to setup and get started with and may be useful in situations where only one worker makes sense (e.g. collecting log files), but it does not benefit from some of the features of Kafka Connect such as fault tolerance. You can start a standalone process with the following command:
+
+
+ $ bin/connect-standalone.sh config/connect-standalone.properties [connector1.properties connector2.json …]
+
+The first parameter is the configuration for the worker. This includes settings such as the Kafka connection parameters, serialization format, and how frequently to commit offsets. The provided example should work well with a local cluster running with the default configuration provided by `config/server.properties`. It will require tweaking to use with a different configuration or production deployment. All workers (both standalone and distributed) require a few configs:
+
+ * `bootstrap.servers` \- List of Kafka servers used to bootstrap connections to Kafka
+ * `key.converter` \- Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the keys in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.
+ * `value.converter` \- Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the values in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.
+ * `plugin.path` (default `null`) - a list of paths that contain Connect plugins (connectors, converters, transformations). Before running quick starts, users must add the absolute path that contains the example FileStreamSourceConnector and FileStreamSinkConnector packaged in `connect-file-4.2.0.jar`, because these connectors are not included by default to the `CLASSPATH` or the `plugin.path` of the Connect worker (see plugin.path property for examples).
+
+
+
+The important configuration options specific to standalone mode are:
+
+ * `offset.storage.file.filename` \- File to store source connector offsets
+
+
+
+The parameters that are configured here are intended for producers and consumers used by Kafka Connect to access the configuration, offset and status topics. For configuration of the producers used by Kafka source tasks and the consumers used by Kafka sink tasks, the same parameters can be used but need to be prefixed with `producer.` and `consumer.` respectively. The only Kafka client parameter that is inherited without a prefix from the worker configuration is `bootstrap.servers`, whic [...]
+
+Client configuration overrides can be configured individually per connector by using the prefixes `producer.override.` and `consumer.override.` for Kafka sources or Kafka sinks respectively. These overrides are included with the rest of the connector's configuration properties.
+
+The remaining parameters are connector configuration files. Each file may either be a Java Properties file or a JSON file containing an object with the same structure as the request body of either the `POST /connectors` endpoint or the `PUT /connectors/{name}/config` endpoint (see the [OpenAPI documentation](/42/generated/connect_rest.yaml)). You may include as many as you want, but all will execute within the same process (on different threads). You can also choose not to specify any co [...]
+
+Distributed mode handles automatic balancing of work, allows you to scale up (or down) dynamically, and offers fault tolerance both in the active tasks and for configuration and offset commit data. Execution is very similar to standalone mode:
+
+
+ $ bin/connect-distributed.sh config/connect-distributed.properties
+
+The difference is in the class which is started and the configuration parameters which change how the Kafka Connect process decides where to store configurations, how to assign work, and where to store offsets and task statues. In the distributed mode, Kafka Connect stores the offsets, configs and task statuses in Kafka topics. It is recommended to manually create the topics for offset, configs and statuses in order to achieve the desired the number of partitions and replication factors. [...]
+
+In particular, the following configuration parameters, in addition to the common settings mentioned above, are critical to set before starting your cluster:
+
+ * `group.id` \- Unique name for the cluster, used in forming the Connect cluster group; note that this **must not conflict** with consumer group IDs
+ * `config.storage.topic` \- Name for the topic to use for storing connector and task configurations; this topic should have a single partition, be replicated, and be configured for compaction
+ * `offset.storage.topic` \- Name for the topic to use for storing offsets; this topic should have many partitions, be replicated, and be configured for compaction
+ * `status.storage.topic` \- Name for the topic to use for storing statuses; this topic can have multiple partitions, be replicated, and be configured for compaction
+
+
+
+Note that in distributed mode the connector configurations are not passed on the command line. Instead, use the REST API described below to create, modify, and destroy connectors.
+
+## Configuring Connectors
+
+Connector configurations are simple key-value mappings. In both standalone and distributed mode, they are included in the JSON payload for the REST request that creates (or modifies) the connector. In standalone mode these can also be defined in a properties file and passed to the Connect process on the command line.
+
+Most configurations are connector dependent, so they can't be outlined here. However, there are a few common options:
+
+ * `name` \- Unique name for the connector. Attempting to register again with the same name will fail.
+ * `connector.class` \- The Java class for the connector
+ * `tasks.max` \- The maximum number of tasks that should be created for this connector. The connector may create fewer tasks if it cannot achieve this level of parallelism.
+ * `key.converter` \- (optional) Override the default key converter set by the worker.
+ * `value.converter` \- (optional) Override the default value converter set by the worker.
+
+
+
+The `connector.class` config supports several formats: the full name or alias of the class for this connector. If the connector is org.apache.kafka.connect.file.FileStreamSinkConnector, you can either specify this full name or use FileStreamSink or FileStreamSinkConnector to make the configuration a bit shorter.
+
+Sink connectors also have a few additional options to control their input. Each sink connector must set one of the following:
+
+ * `topics` \- A comma-separated list of topics to use as input for this connector
+ * `topics.regex` \- A Java regular expression of topics to use as input for this connector
+
+
+
+For any other options, you should consult the documentation for the connector.
+
+## Transformations
+
+Connectors can be configured with transformations to make lightweight message-at-a-time modifications. They can be convenient for data massaging and event routing.
+
+A transformation chain can be specified in the connector configuration.
+
+ * `transforms` \- List of aliases for the transformation, specifying the order in which the transformations will be applied.
+ * `transforms.$alias.type` \- Fully qualified class name for the transformation.
+ * `transforms.$alias.$transformationSpecificConfig` Configuration properties for the transformation
+
+
+
+For example, lets take the built-in file source connector and use a transformation to add a static field.
+
+Throughout the example we'll use schemaless JSON data format. To use schemaless format, we changed the following two lines in `connect-standalone.properties` from true to false:
+
+
+ key.converter.schemas.enable
+ value.converter.schemas.enable
+
+The file source connector reads each line as a String. We will wrap each line in a Map and then add a second field to identify the origin of the event. To do this, we use two transformations:
+
+ * **HoistField** to place the input line inside a Map
+ * **InsertField** to add the static field. In this example we'll indicate that the record came from a file connector
+
+
+
+After adding the transformations, `connect-file-source.properties` file looks as following:
+
+
+ name=local-file-source
+ connector.class=FileStreamSource
+ tasks.max=1
+ file=test.txt
+ topic=connect-test
+ transforms=MakeMap, InsertSource
+ transforms.MakeMap.type=org.apache.kafka.connect.transforms.HoistField$Value
+ transforms.MakeMap.field=line
+ transforms.InsertSource.type=org.apache.kafka.connect.transforms.InsertField$Value
+ transforms.InsertSource.static.field=data_source
+ transforms.InsertSource.static.value=test-file-source
+
+All the lines starting with `transforms` were added for the transformations. You can see the two transformations we created: "InsertSource" and "MakeMap" are aliases that we chose to give the transformations. The transformation types are based on the list of built-in transformations you can see below. Each transformation type has additional configuration: HoistField requires a configuration called "field", which is the name of the field in the map that will include the original String fr [...]
+
+When we ran the file source connector on my sample file without the transformations, and then read them using `kafka-console-consumer.sh`, the results were:
+
+
+ "foo"
+ "bar"
+ "hello world"
+
+We then create a new file connector, this time after adding the transformations to the configuration file. This time, the results will be:
+
+
+ {"line":"foo","data_source":"test-file-source"}
+ {"line":"bar","data_source":"test-file-source"}
+ {"line":"hello world","data_source":"test-file-source"}
+
+You can see that the lines we've read are now part of a JSON map, and there is an extra field with the static value we specified. This is just one example of what you can do with transformations.
+
+### Included transformations
+
+Several widely-applicable data and routing transformations are included with Kafka Connect:
+
+ * Cast \- Cast fields or the entire key or value to a specific type
+ * DropHeaders \- Remove headers by name
+ * ExtractField \- Extract a specific field from Struct and Map and include only this field in results
+ * Filter \- Removes messages from all further processing. This is used with a predicate to selectively filter certain messages
+ * Flatten \- Flatten a nested data structure
+ * HeaderFrom \- Copy or move fields in the key or value to the record headers
+ * HoistField \- Wrap the entire event as a single field inside a Struct or a Map
+ * InsertField \- Add a field using either static data or record metadata
+ * InsertHeader \- Add a header using static data
+ * MaskField \- Replace field with valid null value for the type (0, empty string, etc) or custom replacement (non-empty string or numeric value only)
+ * RegexRouter \- modify the topic of a record based on original topic, replacement string and a regular expression
+ * ReplaceField \- Filter or rename fields
+ * SetSchemaMetadata \- modify the schema name or version
+ * TimestampConverter \- Convert timestamps between different formats
+ * TimestampRouter \- Modify the topic of a record based on original topic and timestamp. Useful when using a sink that needs to write to different tables or indexes based on timestamps
+ * ValueToKey \- Replace the record key with a new key formed from a subset of fields in the record value
+
+
+
+Details on how to configure each transformation are listed below:
+
+{{< include-html file="/static/42/generated/connect_transforms.html" >}}
+
+### Predicates
+
+Transformations can be configured with predicates so that the transformation is applied only to messages which satisfy some condition. In particular, when combined with the **Filter** transformation predicates can be used to selectively filter out certain messages.
+
+Predicates are specified in the connector configuration.
+
+ * `predicates` \- Set of aliases for the predicates to be applied to some of the transformations.
+ * `predicates.$alias.type` \- Fully qualified class name for the predicate.
+ * `predicates.$alias.$predicateSpecificConfig` \- Configuration properties for the predicate.
+
+
+
+All transformations have the implicit config properties `predicate` and `negate`. A predicular predicate is associated with a transformation by setting the transformation's `predicate` config to the predicate's alias. The predicate's value can be reversed using the `negate` configuration property.
+
+For example, suppose you have a source connector which produces messages to many different topics and you want to:
+
+ * filter out the messages in the 'foo' topic entirely
+ * apply the ExtractField transformation with the field name 'other_field' to records in all topics _except_ the topic 'bar'
+
+
+
+To do this we need first to filter out the records destined for the topic 'foo'. The Filter transformation removes records from further processing, and can use the TopicNameMatches predicate to apply the transformation only to records in topics which match a certain regular expression. TopicNameMatches's only configuration property is `pattern` which is a Java regular expression for matching against the topic name. The configuration would look like this:
+
+
+ transforms=Filter
+ transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
+ transforms.Filter.predicate=IsFoo
+
+ predicates=IsFoo
+ predicates.IsFoo.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
+ predicates.IsFoo.pattern=foo
+
+Next we need to apply ExtractField only when the topic name of the record is not 'bar'. We can't just use TopicNameMatches directly, because that would apply the transformation to matching topic names, not topic names which do _not_ match. The transformation's implicit `negate` config properties allows us to invert the set of records which a predicate matches. Adding the configuration for this to the previous example we arrive at:
+
+
+ transforms=Filter,Extract
+ transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
+ transforms.Filter.predicate=IsFoo
+
+ transforms.Extract.type=org.apache.kafka.connect.transforms.ExtractField$Key
+ transforms.Extract.field=other_field
+ transforms.Extract.predicate=IsBar
+ transforms.Extract.negate=true
+
+ predicates=IsFoo,IsBar
+ predicates.IsFoo.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
+ predicates.IsFoo.pattern=foo
+
+ predicates.IsBar.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
+ predicates.IsBar.pattern=bar
+
+Kafka Connect includes the following predicates:
+
+ * `TopicNameMatches` \- matches records in a topic with a name matching a particular Java regular expression.
+ * `HasHeaderKey` \- matches records which have a header with the given key.
+ * `RecordIsTombstone` \- matches tombstone records, that is records with a null value.
+
+
+
+Details on how to configure each predicate are listed below:
+
+{{< include-html file="/static/42/generated/connect_predicates.html" >}}
+
+## REST API
+
+Since Kafka Connect is intended to be run as a service, it also provides a REST API for managing connectors. This REST API is available in both standalone and distributed mode. The REST API server can be configured using the `listeners` configuration option. This field should contain a list of listeners in the following format: `protocol://host:port,protocol2://host2:port2`. Currently supported protocols are `http` and `https`. For example:
+
+
+ listeners=http://localhost:8080,https://localhost:8443
+
+By default, if no `listeners` are specified, the REST server runs on port 8083 using the HTTP protocol. When using HTTPS, the configuration has to include the SSL configuration. By default, it will use the `ssl.*` settings. In case it is needed to use different configuration for the REST API than for connecting to Kafka brokers, the fields can be prefixed with `listeners.https`. When using the prefix, only the prefixed options will be used and the `ssl.*` options without the prefix will [...]
+
+ * `ssl.keystore.location`
+ * `ssl.keystore.password`
+ * `ssl.keystore.type`
+ * `ssl.key.password`
+ * `ssl.truststore.location`
+ * `ssl.truststore.password`
+ * `ssl.truststore.type`
+ * `ssl.enabled.protocols`
+ * `ssl.provider`
+ * `ssl.protocol`
+ * `ssl.cipher.suites`
+ * `ssl.keymanager.algorithm`
+ * `ssl.secure.random.implementation`
+ * `ssl.trustmanager.algorithm`
+ * `ssl.endpoint.identification.algorithm`
+ * `ssl.client.auth`
+
+
+
+The REST API is used not only by users to monitor / manage Kafka Connect. In distributed mode, it is also used for the Kafka Connect cross-cluster communication. Some requests received on the follower nodes REST API will be forwarded to the leader node REST API. In case the URI under which is given host reachable is different from the URI which it listens on, the configuration options `rest.advertised.host.name`, `rest.advertised.port` and `rest.advertised.listener` can be used to change [...]
+
+The following are the currently supported REST API endpoints:
+
+ * `GET /connectors` \- return a list of active connectors
+ * `POST /connectors` \- create a new connector; the request body should be a JSON object containing a string `name` field and an object `config` field with the connector configuration parameters. The JSON object may also optionally contain a string `initial_state` field which can take the following values - `STOPPED`, `PAUSED` or `RUNNING` (the default value)
+ * `GET /connectors/{name}` \- get information about a specific connector
+ * `GET /connectors/{name}/config` \- get the configuration parameters for a specific connector
+ * `PUT /connectors/{name}/config` \- update the configuration parameters for a specific connector
+ * `PATCH /connectors/{name}/config` \- patch the configuration parameters for a specific connector, where `null` values in the JSON body indicates removing of the key from the final configuration
+ * `GET /connectors/{name}/status` \- get current status of the connector, including if it is running, failed, paused, etc., which worker it is assigned to, error information if it has failed, and the state of all its tasks
+ * `GET /connectors/{name}/tasks` \- get a list of tasks currently running for a connector along with their configurations
+ * `GET /connectors/{name}/tasks/{taskid}/status` \- get current status of the task, including if it is running, failed, paused, etc., which worker it is assigned to, and error information if it has failed
+ * `PUT /connectors/{name}/pause` \- pause the connector and its tasks, which stops message processing until the connector is resumed. Any resources claimed by its tasks are left allocated, which allows the connector to begin processing data quickly once it is resumed.
+ * `PUT /connectors/{name}/stop` \- stop the connector and shut down its tasks, deallocating any resources claimed by its tasks. This is more efficient from a resource usage standpoint than pausing the connector, but can cause it to take longer to begin processing data once resumed. Note that the offsets for a connector can be only modified via the offsets management endpoints if it is in the stopped state
+ * `PUT /connectors/{name}/resume` \- resume a paused or stopped connector (or do nothing if the connector is not paused or stopped)
+ * `POST /connectors/{name}/restart?includeTasks=<true|false>&onlyFailed=<true|false>` \- restart a connector and its tasks instances.
+ * the "includeTasks" parameter specifies whether to restart the connector instance and task instances ("includeTasks=true") or just the connector instance ("includeTasks=false"), with the default ("false") preserving the same behavior as earlier versions.
+ * the "onlyFailed" parameter specifies whether to restart just the instances with a FAILED status ("onlyFailed=true") or all instances ("onlyFailed=false"), with the default ("false") preserving the same behavior as earlier versions.
+ * `POST /connectors/{name}/tasks/{taskId}/restart` \- restart an individual task (typically because it has failed)
+ * `DELETE /connectors/{name}` \- delete a connector, halting all tasks and deleting its configuration
+ * `GET /connectors/{name}/topics` \- get the set of topics that a specific connector is using since the connector was created or since a request to reset its set of active topics was issued
+ * `PUT /connectors/{name}/topics/reset` \- send a request to empty the set of active topics of a connector
+ * Offsets management endpoints (see [KIP-875](https://cwiki.apache.org/confluence/x/Io3GDQ) for more details):
+ * `GET /connectors/{name}/offsets` \- get the current offsets for a connector
+ * `DELETE /connectors/{name}/offsets` \- reset the offsets for a connector. The connector must exist and must be in the stopped state (see `PUT /connectors/{name}/stop`)
+ * `PATCH /connectors/{name}/offsets` \- alter the offsets for a connector. The connector must exist and must be in the stopped state (see `PUT /connectors/{name}/stop`). The request body should be a JSON object containing a JSON array `offsets` field, similar to the response body of the `GET /connectors/{name}/offsets` endpoint. An example request body for the `FileStreamSourceConnector`:
+
+ {
+ "offsets": [
+ {
+ "partition": {
+ "filename": "test.txt"
+ },
+ "offset": {
+ "position": 30
+ }
+ }
+ ]
+ }
+
+An example request body for the `FileStreamSinkConnector`:
+
+ {
+ "offsets": [
+ {
+ "partition": {
+ "kafka_topic": "test",
+ "kafka_partition": 0
+ },
+ "offset": {
+ "kafka_offset": 5
+ }
+ },
+ {
+ "partition": {
+ "kafka_topic": "test",
+ "kafka_partition": 1
+ },
+ "offset": null
+ }
+ ]
+ }
+
+The "offset" field may be null to reset the offset for a specific partition (applicable to both source and sink connectors). Note that the request body format depends on the connector implementation in the case of source connectors, whereas there is a common format across all sink connectors.
+
+
+
+Kafka Connect also provides a REST API for getting information about connector plugins:
+
+ * `GET /connector-plugins`\- return a list of connector plugins installed in the Kafka Connect cluster. Note that the API only checks for connectors on the worker that handles the request, which means you may see inconsistent results, especially during a rolling upgrade if you add new connector jars
+ * `GET /connector-plugins/{plugin-type}/config` \- get the configuration definition for the specified plugin.
+ * `PUT /connector-plugins/{connector-type}/config/validate` \- validate the provided configuration values against the configuration definition. This API performs per config validation, returns suggested values and error messages during validation.
+
+
+
+The following is a supported REST request at the top-level (root) endpoint:
+
+ * `GET /`\- return basic information about the Kafka Connect cluster such as the version of the Connect worker that serves the REST request (including git commit ID of the source code) and the Kafka cluster ID that is connected to.
+
+
+The `admin.listeners` configuration can be used to configure admin REST APIs on Kafka Connect's REST API server. Similar to the `listeners` configuration, this field should contain a list of listeners in the following format: `protocol://host:port,protocol2://host2:port2`. Currently supported protocols are `http` and `https`. For example:
+
+
+ admin.listeners=http://localhost:8080,https://localhost:8443
+
+By default, if `admin.listeners` is not configured, the admin REST APIs will be available on the regular listeners.
+
+The following are the currently supported admin REST API endpoints:
+
+ * `GET /admin/loggers` \- list the current loggers that have their levels explicitly set and their log levels
+ * `GET /admin/loggers/{name}` \- get the log level for the specified logger
+ * `PUT /admin/loggers/{name}` \- set the log level for the specified logger
+
+
+
+See [KIP-495](https://cwiki.apache.org/confluence/x/-4tTBw) for more details about the admin logger REST APIs.
+
+For the complete specification of the Kafka Connect REST API, see the [OpenAPI documentation](/42/generated/connect_rest.yaml)
+
+## Error Reporting in Connect
+
+Kafka Connect provides error reporting to handle errors encountered along various stages of processing. By default, any error encountered during conversion or within transformations will cause the connector to fail. Each connector configuration can also enable tolerating such errors by skipping them, optionally writing each error and the details of the failed operation and problematic record (with various levels of detail) to the Connect application log. These mechanisms also capture err [...]
+
+To report errors within a connector's converter, transforms, or within the sink connector itself to the log, set `errors.log.enable=true` in the connector configuration to log details of each error and problem record's topic, partition, and offset. For additional debugging purposes, set `errors.log.include.messages=true` to also log the problem record key, value, and headers to the log (note this may log sensitive information).
+
+To report errors within a connector's converter, transforms, or within the sink connector itself to a dead letter queue topic, set `errors.deadletterqueue.topic.name`, and optionally `errors.deadletterqueue.context.headers.enable=true`.
+
+By default connectors exhibit "fail fast" behavior immediately upon an error or exception. This is equivalent to adding the following configuration properties with their defaults to a connector configuration:
+
+
+ # disable retries on failure
+ errors.retry.timeout=0
+
+ # do not log the error and their contexts
+ errors.log.enable=false
+
+ # do not record errors in a dead letter queue topic
+ errors.deadletterqueue.topic.name=
+
+ # Fail on first error
+ errors.tolerance=none
+
+These and other related connector configuration properties can be changed to provide different behavior. For example, the following configuration properties can be added to a connector configuration to setup error handling with multiple retries, logging to the application logs and the `my-connector-errors` Kafka topic, and tolerating all errors by reporting them rather than failing the connector task:
+
+
+ # retry for at most 10 minutes times waiting up to 30 seconds between consecutive failures
+ errors.retry.timeout=600000
+ errors.retry.delay.max.ms=30000
+
+ # log error context along with application logs, but do not include configs and messages
+ errors.log.enable=true
+ errors.log.include.messages=false
+
+ # produce error context into the Kafka topic
+ errors.deadletterqueue.topic.name=my-connector-errors
+
+ # Tolerate all errors.
+ errors.tolerance=all
+
+## Exactly-once support
+
+Kafka Connect is capable of providing exactly-once semantics for sink connectors (as of version 0.11.0) and source connectors (as of version 3.3.0). Please note that **support for exactly-once semantics is highly dependent on the type of connector you run.** Even if you set all the correct worker properties in the configuration for each node in a cluster, if a connector is not designed to, or cannot take advantage of the capabilities of the Kafka Connect framework, exactly-once may not b [...]
+
+### Sink connectors
+
+If a sink connector supports exactly-once semantics, to enable exactly-once at the Connect worker level, you must ensure its consumer group is configured to ignore records in aborted transactions. You can do this by setting the worker property `consumer.isolation.level` to `read_committed` or, if running a version of Kafka Connect that supports it, using a connector client config override policy that allows the `consumer.override.isolation.level` property to be set to `read_committed` in [...]
+
+### Source connectors
+
+If a source connector supports exactly-once semantics, you must configure your Connect cluster to enable framework-level support for exactly-once source connectors. Additional ACLs may be necessary if running against a secured Kafka cluster. Note that exactly-once support for source connectors is currently only available in distributed mode; standalone Connect workers cannot provide exactly-once semantics.
+
+#### Worker configuration
+
+For new Connect clusters, set the `exactly.once.source.support` property to `enabled` in the worker config for each node in the cluster. For existing clusters, two rolling upgrades are necessary. During the first upgrade, the `exactly.once.source.support` property should be set to `preparing`, and during the second, it should be set to `enabled`.
+
+#### ACL requirements
+
+With exactly-once source support enabled, or with `exactly.once.source.support` set to `preparing`, the principal for each Connect worker will require the following ACLs:
+
+<table>
+<tr>
+<th>
+
+Operation
+</th>
+<th>
+
+Resource Type
+</th>
+<th>
+
+Resource Name
+</th>
+<th>
+
+Note
+</th> </tr>
+<tr>
+<td>
+
+Write
+</td>
+<td>
+
+TransactionalId
+</td>
+<td>
+
+`connect-cluster-${groupId}`, where `${groupId}` is the `group.id` of the cluster
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+Describe
+</td>
+<td>
+
+TransactionalId
+</td>
+<td>
+
+`connect-cluster-${groupId}`, where `${groupId}` is the `group.id` of the cluster
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+IdempotentWrite
+</td>
+<td>
+
+Cluster
+</td>
+<td>
+
+ID of the Kafka cluster that hosts the worker's config topic
+</td>
+<td>
+
+The IdempotentWrite ACL has been deprecated as of 2.8 and will only be necessary for Connect clusters running on pre-2.8 Kafka clusters
+</td> </tr> </table>
+
+And with exactly-once source enabled (but not if `exactly.once.source.support` is set to `preparing`), the principal for each individual connector will require the following ACLs:
+
+<table>
+<tr>
+<th>
+
+Operation
+</th>
+<th>
+
+Resource Type
+</th>
+<th>
+
+Resource Name
+</th>
+<th>
+
+Note
+</th> </tr>
+<tr>
+<td>
+
+Write
+</td>
+<td>
+
+TransactionalId
+</td>
+<td>
+
+`${groupId}-${connector}-${taskId}`, for each task that the connector will create, where `${groupId}` is the `group.id` of the Connect cluster, `${connector}` is the name of the connector, and `${taskId}` is the ID of the task (starting from zero)
+</td>
+<td>
+
+A wildcard prefix of `${groupId}-${connector}*` can be used for convenience if there is no risk of conflict with other transactional IDs or if conflicts are acceptable to the user.
+</td> </tr>
+<tr>
+<td>
+
+Describe
+</td>
+<td>
+
+TransactionalId
+</td>
+<td>
+
+`${groupId}-${connector}-${taskId}`, for each task that the connector will create, where `${groupId}` is the `group.id` of the Connect cluster, `${connector}` is the name of the connector, and `${taskId}` is the ID of the task (starting from zero)
+</td>
+<td>
+
+A wildcard prefix of `${groupId}-${connector}*` can be used for convenience if there is no risk of conflict with other transactional IDs or if conflicts are acceptable to the user.
+</td> </tr>
+<tr>
+<td>
+
+Write
+</td>
+<td>
+
+Topic
+</td>
+<td>
+
+Offsets topic used by the connector, which is either the value of the `offsets.storage.topic` property in the connector’s configuration if provided, or the value of the `offsets.storage.topic` property in the worker’s configuration if not.
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+Read
+</td>
+<td>
+
+Topic
+</td>
+<td>
+
+Offsets topic used by the connector, which is either the value of the `offsets.storage.topic` property in the connector’s configuration if provided, or the value of the `offsets.storage.topic` property in the worker’s configuration if not.
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+Describe
+</td>
+<td>
+
+Topic
+</td>
+<td>
+
+Offsets topic used by the connector, which is either the value of the `offsets.storage.topic` property in the connector’s configuration if provided, or the value of the `offsets.storage.topic` property in the worker’s configuration if not.
+</td>
+<td>
+
+
+</td> </tr>
+<tr>
+<td>
+
+Create
+</td>
+<td>
+
+Topic
+</td>
+<td>
+
+Offsets topic used by the connector, which is either the value of the `offsets.storage.topic` property in the connector’s configuration if provided, or the value of the `offsets.storage.topic` property in the worker’s configuration if not.
+</td>
+<td>
+
+Only necessary if the offsets topic for the connector does not exist yet
+</td> </tr>
+<tr>
+<td>
+
+IdempotentWrite
+</td>
+<td>
+
+Cluster
+</td>
+<td>
+
+ID of the Kafka cluster that the source connector writes to
+</td>
+<td>
+
+The IdempotentWrite ACL has been deprecated as of 2.8 and will only be necessary for Connect clusters running on pre-2.8 Kafka clusters
+</td> </tr> </table>
+
+## Plugin Discovery
+
+Plugin discovery is the name for the strategy which the Connect worker uses to find plugin classes and make them accessible to configure and run in connectors. This is controlled by the plugin.discovery worker configuration, and has a significant impact on worker startup time. `service_load` is the fastest strategy, but care should be taken to verify that plugins are compatible before setting this configuration to `service_load`.
+
+Prior to version 3.6, this strategy was not configurable, and behaved like the `only_scan` mode which is compatible with all plugins. For version 3.6 and later, this mode defaults to `hybrid_warn` which is also compatible with all plugins, but logs a warning for plugins which are incompatible with `service_load`. The `hybrid_fail` strategy stops the worker with an error if a plugin incompatible with `service_load` is detected, asserting that all plugins are compatible. Finally, the `serv [...]
+
+### Verifying Plugin Compatibility
+
+To verify if all of your plugins are compatible with `service_load`, first ensure that you are using version 3.6 or later of Kafka Connect. You can then perform one of the following checks:
+
+ * Start your worker with the default `hybrid_warn`strategy, and WARN logs enabled for the `org.apache.kafka.connect` package. At least one WARN log message mentioning the `plugin.discovery` configuration should be printed. This log message will explicitly say that all plugins are compatible, or list the incompatible plugins.
+ * Start your worker in a test environment with `hybrid_fail`. If all plugins are compatible, startup will succeed. If at least one plugin is not compatible the worker will fail to start up, and all incompatible plugins will be listed in the exception.
+
+
+
+If the verification step succeeds, then your current set of installed plugins is compatible, and it should be safe to change the `plugin.discovery` configuration to `service_load`. If the verification fails, you cannot use `service_load` strategy and should take note of the list of incompatible plugins. All plugins must be addressed before using the `service_load` strategy. It is recommended to perform this verification after installing or changing plugin versions, and the verification c [...]
+
+### Operators: Artifact Migration
+
+As an operator of Connect, if you discover incompatible plugins, there are multiple ways to resolve the incompatibility. They are listed below from most to least preferable.
+
+ 1. Check the latest release from your plugin provider, and if it is compatible, upgrade.
+ 2. Contact your plugin provider and request that they migrate the plugin to be compatible, following the source migration instructions, and then upgrade to the compatible version.
+ 3. Migrate the plugin artifacts yourself using the included migration script.
+
+
+
+The migration script is located in `bin/connect-plugin-path.sh` and `bin\windows\connect-plugin-path.bat` of your Kafka installation. The script can migrate incompatible plugin artifacts already installed on your Connect worker's `plugin.path` by adding or modifying JAR or resource files. This is not suitable for environments using code-signing, as this can change artifacts such that they will fail signature verification. View the built-in help with `--help`.
+
+To perform a migration, first use the `list` subcommand to get an overview of the plugins available to the script. You must tell the script where to find plugins, which can be done with the repeatable `--worker-config`, `--plugin-path`, and `--plugin-location` arguments. The script will ignore plugins on the classpath, so any custom plugins on your classpath should be moved to the plugin path in order to be used with this migration script, or migrated manually. Be sure to compare the out [...]
+
+Once you see that all incompatible plugins are included in the listing, you can proceed to dry-run the migration with `sync-manifests --dry-run`. This will perform all parts of the migration, except for writing the results of the migration to disk. Note that the `sync-manifests` command requires all specified paths to be writable, and may alter the contents of the directories. Make a backup of your plugins in the specified paths, or copy them to a writable directory.
+
+Ensure that you have a backup of your plugins and the dry-run succeeds before removing the `--dry-run` flag and actually running the migration. If the migration fails without the `--dry-run` flag, then the partially migrated artifacts should be discarded. The migration is idempotent, so running it multiple times and on already-migrated plugins is safe. After the script finishes, you should verify the migration is complete. The migration script is suitable for use in a Continuous Integrat [...]
+
+### Developers: Source Migration
+
+To make plugins compatible with `service_load`, it is necessary to add [ServiceLoader](https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html) manifests to your source code, which should then be packaged in the release artifact. Manifests are resource files in `META-INF/services/` named after their superclass type, and contain a list of fully-qualified subclass names, one on each line.
+
+In order for a plugin to be compatible, it must appear as a line in a manifest corresponding to the plugin superclass it extends. If a single plugin implements multiple plugin interfaces, then it should appear in a manifest for each interface it implements. If you have no classes for a certain type of plugin, you do not need to include a manifest file for that type. If you have classes which should not be visible as plugins, they should be marked abstract. The following types are expecte [...]
+
+ * `org.apache.kafka.connect.sink.SinkConnector`
+ * `org.apache.kafka.connect.source.SourceConnector`
+ * `org.apache.kafka.connect.storage.Converter`
+ * `org.apache.kafka.connect.storage.HeaderConverter`
+ * `org.apache.kafka.connect.transforms.Transformation`
+ * `org.apache.kafka.connect.transforms.predicates.Predicate`
+ * `org.apache.kafka.common.config.provider.ConfigProvider`
+ * `org.apache.kafka.connect.rest.ConnectRestExtension`
+ * `org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy`
+
+
+
+For example, if you only have one connector with the fully-qualified name `com.example.MySinkConnector`, then only one manifest file must be added to resources in `META-INF/services/org.apache.kafka.connect.sink.SinkConnector`, and the contents should be similar to the following:
+
+
+ # license header or comment
+ com.example.MySinkConnector
+
+You should then verify that your manifests are correct by using the verification steps with a pre-release artifact. If the verification succeeds, you can then release the plugin normally, and operators can upgrade to the compatible version.
+
+## Security
+
+It's important to understand the security concerns inherent to Connect. First, Connect allows running custom plugins. These plugins can run arbitrary code, so you must trust them before installing them in your Connect clusters. By default, the REST API is unsecured and allows anyone that can access it to start and stop connectors. You should only directly expose the REST API to trusted users, otherwise it's easy to gain arbitrary code execution on Connect workers. By default, connectors [...]
diff --git a/docs/documentation/index.html b/docs/operations/_index.md
similarity index 87%
copy from docs/documentation/index.html
copy to docs/operations/_index.md
index 1d7507f30a9..c5c8a0ba7a8 100644
--- a/docs/documentation/index.html
+++ b/docs/operations/_index.md
@@ -1,3 +1,13 @@
+---
+title: Operations
+description:
+weight: 6
+tags: ['kafka', 'docs', 'ops']
+aliases:
+keywords:
+type: docs
+---
+
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
@@ -15,4 +25,4 @@
limitations under the License.
-->
-<!--#include virtual="../documentation.html" -->
\ No newline at end of file
+
diff --git a/docs/operations/basic-kafka-operations.md b/docs/operations/basic-kafka-operations.md
new file mode 100644
index 00000000000..700aa47c10d
--- /dev/null
+++ b/docs/operations/basic-kafka-operations.md
@@ -0,0 +1,652 @@
+---
+title: Basic Kafka Operations
+description: Basic Kafka Operations
+weight: 1
+tags: ['kafka', 'docs']
+aliases:
+keywords:
+type: docs
+---
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+
+This section will review the most common operations you will perform on your Kafka cluster. All of the tools reviewed in this section are available under the `bin/` directory of the Kafka distribution and each tool will print details on all possible commandline options if it is run with no arguments.
+
+## Adding and removing topics
+
+You have the option of either adding topics manually or having them be created automatically when data is first published to a non-existent topic. If topics are auto-created then you may want to tune the default topic configurations used for auto-created topics.
+
+Topics are added and modified using the topic tool:
+
+
+ $ bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my_topic_name \
+ --partitions 20 --replication-factor 3 --config x=y
+
+The replication factor controls how many servers will replicate each message that is written. If you have a replication factor of 3 then up to 2 servers can fail before you will lose access to your data. We recommend you use a replication factor of 2 or 3 so that you can transparently bounce machines without interrupting data consumption.
+
+The partition count controls how many logs the topic will be sharded into. There are several impacts of the partition count. First each partition must fit entirely on a single server. So if you have 20 partitions the full data set (and read and write load) will be handled by no more than 20 servers (not counting replicas). Finally the partition count impacts the maximum parallelism of your consumers. This is discussed in greater detail in the concepts section.
+
+Each sharded partition log is placed into its own folder under the Kafka log directory. The name of such folders consists of the topic name, appended by a dash (-) and the partition id. Since a typical folder name can not be over 255 characters long, there will be a limitation on the length of topic names. We assume the number of partitions will not ever be above 100,000. Therefore, topic names cannot be longer than 249 characters. This leaves just enough room in the folder name for a da [...]
+
+The configurations added on the command line override the default settings the server has for things like the length of time data should be retained. The complete set of per-topic configurations is documented here.
+
+## Modifying topics
+
+You can change the configuration or partitioning of a topic using the same topic tool.
+
+To add partitions you can do
+
+
+ $ bin/kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic my_topic_name \
+ --partitions 40
+
+Be aware that one use case for partitions is to semantically partition data, and adding partitions doesn't change the partitioning of existing data so this may disturb consumers if they rely on that partition. That is if data is partitioned by `hash(key) % number_of_partitions` then this partitioning will potentially be shuffled by adding partitions but Kafka will not attempt to automatically redistribute data in any way.
+
+To add configs:
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my_topic_name --alter --add-config x=y
+
+To remove a config:
+
+
+ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my_topic_name --alter --delete-config x
+
+And finally deleting a topic:
+
+
+ $ bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my_topic_name
+
+Kafka does not currently support reducing the number of partitions for a topic.
+
+Instructions for changing the replication factor of a topic can be found here.
+
+## Graceful shutdown
+
+The Kafka cluster will automatically detect any broker shutdown or failure and elect new leaders for the partitions on that machine. This will occur whether a server fails or it is brought down intentionally for maintenance or configuration changes. For the latter cases Kafka supports a more graceful mechanism for stopping a server than just killing it. When a server is stopped gracefully it has two optimizations it will take advantage of:
+
+ 1. It will sync all its logs to disk to avoid needing to do any log recovery when it restarts (i.e. validating the checksum for all messages in the tail of the log). Log recovery takes time so this speeds up intentional restarts.
+ 2. It will migrate any partitions the server is the leader for to other replicas prior to shutting down. This will make the leadership transfer faster and minimize the time each partition is unavailable to a few milliseconds.
+Syncing the logs will happen automatically whenever the server is stopped other than by a hard kill, but the controlled leadership migration requires using a special setting:
+
+
+ controlled.shutdown.enable=true
+
+Note that controlled shutdown will only succeed if _all_ the partitions hosted on the broker have replicas (i.e. the replication factor is greater than 1 _and_ at least one of these replicas is alive). This is generally what you want since shutting down the last replica would make that topic partition unavailable.
+
+## Balancing leadership
+
+Whenever a broker stops or crashes, leadership for that broker's partitions transfers to other replicas. When the broker is restarted it will only be a follower for all its partitions, meaning it will not be used for client reads and writes.
+
+To avoid this imbalance, Kafka has a notion of preferred replicas. If the list of replicas for a partition is 1,5,9 then node 1 is preferred as the leader to either node 5 or 9 because it is earlier in the replica list. By default the Kafka cluster will try to restore leadership to the preferred replicas. This behaviour is configured with:
+
+
+ auto.leader.rebalance.enable=true
+
+You can also set this to false, but you will then need to manually restore leadership to the restored replicas by running the command:
+
+
+ $ bin/kafka-leader-election.sh --bootstrap-server localhost:9092 --election-type preferred --all-topic-partitions
+
+## Balancing replicas across racks
+
+The rack awareness feature spreads replicas of the same partition across different racks. This extends the guarantees Kafka provides for broker-failure to cover rack-failure, limiting the risk of data loss should all the brokers on a rack fail at once. The feature can also be applied to other broker groupings such as availability zones in EC2.
+
+You can specify that a broker belongs to a particular rack by adding a property to the broker config:
+
+
+ broker.rack=my-rack-id
+
+When a topic is created, modified or replicas are redistributed, the rack constraint will be honoured, ensuring replicas span as many racks as they can (a partition will span min(#racks, replication-factor) different racks).
+
+The algorithm used to assign replicas to brokers ensures that the number of leaders per broker will be constant, regardless of how brokers are distributed across racks. This ensures balanced throughput.
+
+However if racks are assigned different numbers of brokers, the assignment of replicas will not be even. Racks with fewer brokers will get more replicas, meaning they will use more storage and put more resources into replication. Hence it is sensible to configure an equal number of brokers per rack.
+
+## Mirroring data between clusters & Geo-replication
+
+Kafka administrators can define data flows that cross the boundaries of individual Kafka clusters, data centers, or geographical regions. Please refer to the section on Geo-Replication for further information.
+
+## Checking consumer position
+
+Sometimes it's useful to see the position of your consumers. We have a tool that will show the position of all consumers in a consumer group as well as how far behind the end of the log they are. To run this tool on a consumer group named _my-group_ consuming a topic named _my-topic_ would look like this:
+
+
+ $ bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group
+ TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
+ my-topic 0 2 4 2 consumer-1-029af89c-873c-4751-a720-cefd41a669d6 /127.0.0.1 consumer-1
+ my-topic 1 2 3 1 consumer-1-029af89c-873c-4751-a720-cefd41a669d6 /127.0.0.1 consumer-1
+ my-topic 2 2 3 1 consumer-2-42c1abd4-e3b2-425d-a8bb-e1ea49b29bb2 /127.0.0.1 consumer-2
+
+## Managing groups
+
+With the GroupCommand tool, we can list groups of all types, including consumer groups, share groups and streams groups. Each type of group has its own tool for administering groups of that type. For example, to list all groups in the cluster:
+
+
+ $ bin/kafka-groups.sh --bootstrap-server localhost:9092 --list
+ GROUP TYPE PROTOCOL
+ my-consumer-group Consumer consumer
+ my-share-group Share share
+
+## Managing consumer groups
+
+With the ConsumerGroupCommand tool, we can list, describe, or delete the consumer groups. The consumer group can be deleted manually, or automatically when the last committed offset for that group expires. Manual deletion works only if the group does not have any active members. For example, to list all consumer groups across all topics:
+
+
+ $ bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list
+ test-consumer-group
+
+To view offsets, as mentioned earlier, we "describe" the consumer group like this:
+
+
+ $ bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group
+ TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
+ topic3 0 241019 395308 154289 consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1 consumer2
+ topic2 1 520678 803288 282610 consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1 consumer2
+ topic3 1 241018 398817 157799 consumer2-e76ea8c3-5d30-4299-9005-47eb41f3d3c4 /127.0.0.1 consumer2
+ topic1 0 854144 855809 1665 consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1 consumer1
+ topic2 0 460537 803290 342753 consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1 consumer1
+ topic3 2 243655 398812 155157 consumer4-117fe4d3-c6c1-4178-8ee9-eb4a3954bee0 /127.0.0.1 consumer4
+
+Note that if the consumer group uses the consumer protocol, the admin client needs DESCRIBE access to all the topics used in the group (topics the members are subscribed to). In contrast, the classic protocol does not require all topics DESCRIBE authorization. There are a number of additional "describe" options that can be used to provide more detailed information about a consumer group:
+
+ * \--members: This option provides the list of all active members in the consumer group.
+
+ $ bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group --members
+ CONSUMER-ID HOST CLIENT-ID #PARTITIONS
+ consumer1-3fc8d6f1-581a-4472-bdf3-3515b4aee8c1 /127.0.0.1 consumer1 2
... 47893 lines suppressed ...