blob: bbe667343193feb7cf43c5c938b6294bcf92654a [file] [view]
---
title: Upgrading
description: Find upgrade steps for Kafka clusters and clients, along with compatibility requirements and notable changes across releases.
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.5.0
### Upgrading Servers to 4.5.0 from any version 3.3.x through 4.4.0
### Notable changes in 4.5.0
* `ssl.principal.mapping.rules` now builds the principal name from the same full match that is used to check the rule. Previously, a rule that is not anchored with both `^` and `$`, or that uses alternation, could build the name from a shorter match or apply the replacement twice. For example, `RULE:CN=(.*?),OU=(.*?)/$1/` mapped `CN=bob,OU=eng` to `bobeng` instead of `bob`. Rules anchored with `^` and `$`, such as the documented examples, are not affected. If you use such rules, check that ACLs, quotas and `super.users` refer to the corrected principal names before upgrading.
* The `ConsumerRebalanceListener` interface and the `Consumer#subscribe` overloads that accept it are deprecated and will be removed in Kafka 5.0. Implement `RebalanceListener` instead, whose callbacks receive a `RebalanceConsumer` exposing the operations that are safe to call during a rebalance, and register it with `Consumer#setRebalanceListener` before subscribing. For further details, please refer to [KIP-1306](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/406623733/KIP-1306+Extend+ConsumerRebalanceListener+with+Consumer-Aware+methods).
## Upgrading to 4.4.0
### Upgrading Servers to 4.4.0 from any version 3.3.x through 4.3.0
### Notable changes in 4.4.0
* The `ClientQuotaCallback#updateClusterMetadata` method is deprecated and will be removed in Kafka 5.0. Custom implementations of `ClientQuotaCallback` no longer need to override this method, as a default no-op implementation is now provided. For further details, please refer to [KIP-1200](https://cwiki.apache.org/confluence/x/axBJFg).
* Protocol message readers now limit array and collection allocations when decoding messages. Arrays and collections with more than 1,000,000 elements and flexible-version tagged-field sections with more than 10,000 fields are rejected before allocation. Arrays and collections are initially allocated with a capacity no greater than 1,000 and grow as needed during decoding.
* New configs have been introduced: remote.copy.lag.bytes, remote.copy.lag.ms and their corresponding broker-level configurations. They allow tiered storage redundancy reduced with delayed upload. For further details, please refer to [KIP-1241](https://cwiki.apache.org/confluence/x/A4LMFw).
* The in-memory keystores (used for PEM certificates) now use the default type provided by `KeyStore.getDefaultType()` instead of the hardcoded PKCS12 type.
* Storage directories formatted by the `kafka-storage` tool are no longer forward-compatible. A Kafka broker must be the same version as, or newer than, the `kafka-storage` tool that formatted its directory, regardless of the `--release-version` chosen at format time. For further details, please refer to [KIP-1170](https://cwiki.apache.org/confluence/x/ZYoEFQ).
* The Linux I/O metrics collector now exposes all 7 fields from /proc/self/io via JMX, adding linux-disk-rchar, linux-disk-wchar, linux-disk-syscr, linux-disk-syscw, and linux-disk-cancelled-write-bytes alongside the existing linux-disk-read-bytes and linux-disk-write-bytes. These additional metrics let operators calculate page-cache hit ratios, detect write amplification from filesystem overhead, identify inefficient syscall patterns, and monitor log-compaction I/O activity. For further details, please refer to [KIP-1291](https://cwiki.apache.org/confluence/x/co48G).
* The `kafka-share-groups.sh` tool can be used to initialize share group offsets from a file. This enables a share group to be initialized from the committed offsets of a consumer group. For further details, please refer to [KIP-1323](https://cwiki.apache.org/confluence/x/vY0mGQ).
* Several Yammer-based group coordinator metrics are deprecated and will be removed in Kafka 5.0 in favor of equivalent Kafka Metrics.
Please use `kafka.server:type=group-coordinator-metrics,name=group-count,protocol=classic` instead of `kafka.coordinator.group:type=GroupMetadataManager,name=NumGroups`,
`kafka.server:type=group-coordinator-metrics,name=offset-count` instead of `kafka.coordinator.group:type=GroupMetadataManager,name=NumOffsets`, and
`kafka.server:type=group-coordinator-metrics,name=classic-group-count,state={PreparingRebalance|CompletingRebalance|Stable|Dead|Empty}` instead of the `kafka.coordinator.group:type=GroupMetadataManager,name=NumGroups{PreparingRebalance|CompletingRebalance|Stable|Dead|Empty}` metrics.
For further details, please refer to [KIP-1301](https://cwiki.apache.org/confluence/x/Z5U8G).
* The broker-side OAUTHBEARER JWT validator now fails fast at startup when a JWKS endpoint (`sasl.oauthbearer.jwks.endpoint.url`) is configured but `sasl.oauthbearer.expected.audience` or `sasl.oauthbearer.expected.issuer` is not set. Brokers that previously started without these settings will now fail to start until they are configured. To intentionally accept tokens regardless of their audience or issuer, set the new `sasl.oauthbearer.allow.unverified.audience` or `sasl.oauthbearer.allow.unverified.issuer` configs (both default `false`) to `true`.
* When clients connect to the cluster, they now include cluster and node information to enable detection and handling of misrouted connections. For further details, please refer to [KIP-1242](https://cwiki.apache.org/confluence/x/W4LMFw).
* The `kafka-cluster.sh` tool now provides an `api-versions` command to display the API versions supported by the brokers or controllers, and it accepts both `--bootstrap-server` and `--bootstrap-controller`. As a result, `kafka-broker-api-versions.sh` is deprecated and will be removed in the next major release; use `kafka-cluster.sh api-versions` instead. For further details, please refer to [KIP-1220](https://cwiki.apache.org/confluence/x/-QkbFw).
* The `broker.id` configuration is deprecated and will be removed in Kafka 5.0. Please use `node.id` instead. For further details, please refer to [KIP-1232](https://cwiki.apache.org/confluence/x/Hgp3Fw).
* Tiered storage plugins are now configured with `node.id` in addition to `broker.id`. Since `broker.id` will no longer be passed to `RemoteStorageManager` and `RemoteLogMetadataManager` implementations in Kafka 5.0, plugins should read `node.id` instead. For further details, please refer to [KIP-1232](https://cwiki.apache.org/confluence/x/Hgp3Fw).
* Brokers can now record a human-readable description of each streams group's processing topology via a pluggable backend, retrievable through `Admin#describeStreamsGroups` and `kafka-streams-groups.sh --describe --topology`. The feature is disabled unless the new broker configuration `group.streams.topology.description.plugin.class` is set to a `StreamsGroupTopologyDescriptionPlugin` implementation; on the client side, the new Kafka Streams configuration `topology.description.push.enabled` (default `true`) controls whether the client pushes topology descriptions when requested. This adds a new RPC, `StreamsGroupTopologyDescriptionUpdate`, bumps `StreamsGroupDescribe` and `StreamsGroupHeartbeat` to version 1, and introduces the error codes `GROUP_DELETION_FAILED` (134) and `STREAMS_TOPOLOGY_DESCRIPTION_UPDATE_FAILED` (135). `DeleteGroups` is bumped to version 3, adding a per-group `ErrorMessage` field so brokers can report why a group deletion failed (for example, when the plugin fails to delete its stored topology description, the group is not deleted and `GROUP_DELETION_FAILED` is returned; retrying the deletion is safe). For further details, please refer to [KIP-1331](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1331%3A+Streams+Group+Topology+Description+Plugin) and the [Topology Description Plugin](/{version}/streams/developer-guide/topology-description-plugin/) documentation.
* The `kafka-producer-perf-test.sh` tool now supports `--record-key-range`, `--key-distribution`, and `--random-seed` options to control the distribution of record keys. Use `--key-distribution range` for sequential key assignment (round-robin over the key range) or `--key-distribution random` for random key selection. The `--random-seed` option allows reproducible benchmark runs when using random key distribution. For further details, please refer to [KIP-1299](https://cwiki.apache.org/confluence/x/XpQ8G).
* Share groups now support dead-letter queue functionality as outlined in [KIP-1191](https://cwiki.apache.org/confluence/x/fApJFg). Any records which are released (beyond max delivery count) or rejected by the share consumer become eligible for DLQ. Share group DLQ gets enabled when the Kafka feature `share.version` is upgraded to 2. The user can configure a DLQ topic on a share group by setting the dynamic config `errors.deadletterqueue.topic.name` (default `""`) to the name of the DLQ topic. The cluster can be configured to auto create the DLQ topics by setting the dynamic cluster config `errors.deadletterqueue.auto.create.topics.enable` to `true` (default `false`). If auto create is not enabled, the user must create the DLQ topic like a standard Kafka topic and set the dynamic config `errors.deadletterqueue.group.enable` to `true` on the DLQ topic. The DLQ topic name must be prefixed by the value set in the dynamic cluster config `errors.deadletterqueue.topic.name.prefix` (default `dlq.`). The records sent to the DLQ topic by default only contain source record metadata like group, topic name, partition id, offset and delivery count. If original record data is also required, the user must set the dynamic config `errors.deadletterqueue.copy.record.enable` to `true` on the share group.
* Kafka Connect distributed workers now support the `internal.topics.automatic.creation.enable` configuration (default: `true`). When set to `false`, Connect will not automatically create internal topics (offset, config, status, and connector-specific offset topics) and will instead fail at startup if any of these topics are missing. A new `connect-internal-topics.sh` tool is also available for manually creating these topics. For further details, please refer to [KIP-1209](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1209:+Add+configuration+to+control+internal+topic+creation+in+Kafka+Connect).
* Streams groups now support broker-side custom task assignors, registered via the new broker configuration `group.streams.assignors` and selected per group with the new group configuration `streams.assignor.name`. For further details, please refer to [KIP-1357](https://cwiki.apache.org/confluence/x/NoSnGQ).
* Streams groups now support the new broker configuration `group.streams.rack.aware.assignment.tags` and the new group configuration `streams.rack.aware.assignment.tags`, which set the client tag keys for rack-aware standby task assignment. Members missing a listed `client.tag.<key>` receive the new `StreamsGroupHeartbeat` status `MISSING_CLIENT_TAGS` (6), sent only on version 1. The built-in `sticky` assignor does not use the tags yet. For further details, please refer to the [Kafka Streams upgrade guide](/{version}/streams/upgrade-guide/).
* Kafka Streams now supports static membership (`group.instance.id`) with the Streams Rebalance Protocol (`group.protocol=streams`). This requires brokers and clients running 4.4 or newer: brokers older than 4.4 reject `group.instance.id` on the streams group heartbeat with `INVALID_REQUEST`, which is a fatal error that shuts down the Kafka Streams client. Make sure to remove `group.instance.id` from all Streams applications using `group.protocol=streams` and restart them before downgrading brokers below 4.4. For further details, please refer to the [Kafka Streams upgrade guide](/{version}/streams/upgrade-guide/).
* Controllers can now be unregistered from the cluster metadata. A new `kafka-cluster.sh unregister-controller` command and a `--unregister` flag on `kafka-metadata-quorum.sh remove-controller` are provided, backed by the new `Admin#unregisterController` API and the new `UnregisterController` RPC. This introduces the error code `CONTROLLER_ID_NOT_REGISTERED` (136) and requires metadata version `4.4-IV2` (`IBP_4_4_IV2`). For further details, please refer to [KIP-1312](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/406623954/KIP-1312+Support+unregistering+controllers).
* A new client configuration, `bootstrap.resolve.timeout.ms`, controls how DNS resolution of `bootstrap.servers` is performed. The default value of `0` preserves the historical synchronous behavior. Setting a positive value opts into asynchronous bootstrap resolution: the client constructor returns immediately, `NetworkClient` retries DNS resolution up to the configured timeout, and failures are surfaced later as `BootstrapResolutionExceptions` from subsequent API calls. This failure is unrecoverable: once raised, the exception is re-thrown by every API call until the client is closed and re-created after fixing the underlying DNS or `bootstrap.servers` configuration. Both asynchronous bootstrap resolution (enabled by setting `bootstrap.resolve.timeout.ms` to a positive value) and `BootstrapResolutionException` are evolving features and may undergo compatibility-breaking changes in a minor release. For further details, please refer to [KIP-909](https://cwiki.apache.org/confluence/x/MJtbDg). Note that Kafka Streams and Kafka Connect do not support asynchronous bootstrap resolution yet: for every client they create internally, `bootstrap.resolve.timeout.ms` is forced to `0` and a user-supplied positive value is ignored with a warning.
* For tiered-storage topics, time-based local retention (`local.retention.ms`) now uses a segment's last modified time as the age anchor when the segment's largest record timestamp is in the future. Previously such a segment was never removed by time-based retention (its future timestamp kept it perpetually within the retention window) and was only reclaimed once `local.retention.bytes` was breached, even though it had already been uploaded to remote storage. For further details, please refer to [KAFKA-20609](https://issues.apache.org/jira/browse/KAFKA-20609).
* The `org.apache.kafka.automatic.config.providers` allowlist is now applied when dynamic broker configurations are validated and applied.
* `group.consumer.assignors` now fails broker startup with a `ConfigException` when two configured assignors resolve to the same name, for example a built-in listed both by its name and by its class name, or a custom assignor reusing the name of another configured assignor. Such a configuration used to pass startup validation and fail later during group coordinator loading. For further details, please refer to [KAFKA-20843](https://issues.apache.org/jira/browse/KAFKA-20843).
* `telemetry.max.bytes` now also bounds the size of a client's *decompressed* telemetry payload, not just its compressed wire size (this decompressed-size check was introduced in 4.3.1). A push whose decompressed size exceeds this limit is rejected with the retryable `TELEMETRY_TOO_LARGE` error, so the client retries at its normal push interval; previously this was misreported as `INVALID_RECORD`, which permanently disabled telemetry for that client instance. If clients hit this limit, for example after upgrading from 4.3.0, consider raising `telemetry.max.bytes`, since typical metric formats can decompress to many times their compressed size. For further details, please refer to [KAFKA-21076](https://issues.apache.org/jira/browse/KAFKA-21076).
## Upgrading to 4.3.2
### Notable changes in 4.3.2
* Includes a fix for a critical tiered storage bug in which size-based retention could delete data that was still within retention from both local and remote tiers after a leader election ([KAFKA-20732](https://issues.apache.org/jira/browse/KAFKA-20732)).
* Includes a fix for a Kafka Streams issue in which the state directory could be cleaned prematurely under [KIP-1035](https://cwiki.apache.org/confluence/x/uYvOEg), forcing a from-scratch restore ([KAFKA-20805](https://issues.apache.org/jira/browse/KAFKA-20805)).
* Includes fixes for several critical Kafka Streams bugs that could cause a `StreamThread` to die after task corruption, task recycling, or state updater timeouts ([KAFKA-20808](https://issues.apache.org/jira/browse/KAFKA-20808), [KAFKA-20827](https://issues.apache.org/jira/browse/KAFKA-20827), [KAFKA-20721](https://issues.apache.org/jira/browse/KAFKA-20721)).
* Includes a fix for a group coordinator bug in which a consumer group downgrade could leave the group in an invalid state when the classic group metadata is very large ([KAFKA-20845](https://issues.apache.org/jira/browse/KAFKA-20845)).
* Includes a fix for a client telemetry bug in which metrics could be sent to a stale broker IP address after a broker address change ([KAFKA-20393](https://issues.apache.org/jira/browse/KAFKA-20393)).
* Includes a fix for a `NullPointerException` in `MetadataCache#toCluster` that stopped a custom `ClientQuotaCallback` (`client.quota.callback.class`) from receiving cluster metadata updates ([KAFKA-20746](https://issues.apache.org/jira/browse/KAFKA-20746)).
* Protocol message readers now limit array and collection allocations when decoding messages. Arrays and collections with more than 1,000,000 elements and flexible-version tagged-field sections with more than 10,000 fields are rejected before allocation. Arrays and collections are initially allocated with a capacity no greater than 1,000 and grow as needed during decoding.
## Upgrading to 4.3.1
### Notable changes in 4.3.1
* Includes a fix for a critical Kafka Streams native memory leak caused by RocksDB column family handles and `ColumnFamilyOptions` not being released, notably for the offsets column family introduced for [KIP-1035](https://cwiki.apache.org/confluence/x/uYvOEg) ([KAFKA-20616](https://issues.apache.org/jira/browse/KAFKA-20616), [KAFKA-20688](https://issues.apache.org/jira/browse/KAFKA-20688)).
* Includes a fix for a Kafka Streams stale-offset issue that could cause `OffsetOutOfRangeException` on restart ([KAFKA-20663](https://issues.apache.org/jira/browse/KAFKA-20663)).
* Includes a fix for `Admin` partition-leader APIs hanging when a cached leader has left the cluster ([KAFKA-20673](https://issues.apache.org/jira/browse/KAFKA-20673)).
* Includes fixes for spurious group coordinator errors logged after a partition leadership change ([KAFKA-20634](https://issues.apache.org/jira/browse/KAFKA-20634), [KAFKA-20635](https://issues.apache.org/jira/browse/KAFKA-20635)).
## Upgrading to 4.3.0
### Upgrading Servers to 4.3.0 from any version 3.3.x through 4.2.0
Note: Apache Kafka 4.3 only supports KRaft mode - ZooKeeper mode has been removed. As such, **broker upgrades to 4.3.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.3.x. Clusters in ZooKeeper mode have to be [migrated to KRaft mode](/{version}/operations/kraft/#zookeeper-to-kraft-migration) before they can be upgraded to 4.3.x.
**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.3`
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_3_IV0(30, "4.3", "IV0", true)` means this version has metadata changes). Given your current and target versions, a downgrade is only possible if there are no metadata changes in the versions between.
### Notable changes in 4.3.0
* `kafka-configs.sh --alter --delete-config` no longer requires the specified config keys to exist on the target resource. Previously, attempting to delete a non-existent config key raised an `InvalidConfigurationException`. The deletion is now a no-op when the key does not exist, which allows managing configs for offline brokers via `--bootstrap-controller`. For further details, please refer to [KAFKA-20506](https://issues.apache.org/jira/browse/KAFKA-20506).
* Support dynamically changing configs for dynamic quorum controllers. Previously only brokers and static quorum controllers were supported. For further details, please refer to [KAFKA-18928](https://issues.apache.org/jira/browse/KAFKA-18928).
* Two new configs have been introduced: `group.coordinator.cached.buffer.max.bytes` and `share.coordinator.cached.buffer.max.bytes`. They allow the respective coordinators to set the maximum buffer size retained for reuse. For further details, please refer to [KIP-1196](https://cwiki.apache.org/confluence/x/hA5JFg).
* The new config have been introduced: `remote.log.metadata.topic.min.isr` with 2 as default value. You can correct the min.insync.replicas for the existed __remote_log_metadata topic via kafka-configs.sh if needed. For further details, please refer to [KIP-1235](https://cwiki.apache.org/confluence/x/yommFw).
* The new config prefix `remote.log.metadata.admin.` has been introduced. It allows independent configuration of the admin client used by `TopicBasedRemoteLogMetadataManager`. For further details, please refer to [KIP-1208](https://cwiki.apache.org/confluence/x/vYqhFg).
* The `kafka-streams-scala` library is deprecated as of Kafka 4.3 and will be removed in Kafka 5.0. For further details, please refer to the [migration guide](/{version}/streams/developer-guide/scala-migration).
* Kafka Streams now supports opt-in headers-aware state stores for DSL operators via the new `dsl.store.format` config. The config accepts `DEFAULT` or `HEADERS`. Store-supplier APIs use the `DslStoreFormat` enum, whose values are `PLAIN`, `TIMESTAMPED`, and `HEADERS`; `DslStoreFormat.DEFAULT` does not exist. This builds on the headers-aware state store implementations introduced in [KIP-1271](https://cwiki.apache.org/confluence/x/QIM8G). For further details and current DSL result-header limitations, please refer to [KIP-1285](https://cwiki.apache.org/confluence/x/4ow8G).
* Support for cordoning log directories: For further details, please refer to [KIP-1066](https://cwiki.apache.org/confluence/x/Lg_TEg).
* The `group.coordinator.rebalance.protocols` configuration is deprecated and will be removed in Kafka 5.0. In Kafka 5.0, all protocols will always be enabled and controlled solely by feature versions (`group.version`, `streams.version`, `share.version`) via `kafka-features.sh`. For further details, please refer to [KIP-1237](https://cwiki.apache.org/confluence/x/jIqmFw).
* New group configs have been introduced: `share.delivery.count.limit`, `share.partition.max.record.locks` and `share.renew.acknowledge.enable`, along with equivalent broker configs for specifying minimum and maximum values. In addition, the validation of group configs has been improved. For further details, please refer to [KIP-1240](https://cwiki.apache.org/confluence/x/tIHMFw).
* A new `group.coordinator.background.threads` config has been added to control the size of the group coordinator's thread pool used to updating regular expression subscriptions. Previously, the thread pool only had a single thread. Now the thread pool has two threads by default and its size is configurable. For further details, please refer to [KIP-1263](https://cwiki.apache.org/confluence/x/DIE8G).
* New `group.consumer.assignment.interval.ms`, `group.share.assignment.interval.ms` and `group.streams.assignment.interval.ms` configs have been added to set the interval between assignment updates for consumer, share and streams groups, along with broker configs for specifying minimum and maximum values and group configs. These default to an interval of 1 second and previously had an effective value of 0. For further details, please refer to [KIP-1263](https://cwiki.apache.org/confluence/x/DIE8G).
* A new dynamic broker configuration `follower.fetch.last.tiered.offset.enable` (default: `false`) has been added. When enabled on a cluster with tiered storage, a newly added follower replica that has no local data will skip directly to the earliest pending upload offset on the leader, avoiding re-fetching data that is already stored in remote storage. This reduces bootstrap time significantly for large tiered-storage topics. For further details, please refer to [KIP-1023](https://cwiki.apache.org/confluence/x/8op3EQ).
* The `ListOffsets` API has been extended to version 11, adding support for the `EARLIEST_PENDING_UPLOAD_TIMESTAMP` (-6) timestamp type. This allows clients to query the earliest offset on the leader that has not yet been uploaded to tiered storage. For further details, please refer to [KIP-1023](https://cwiki.apache.org/confluence/x/8op3EQ).
## Upgrading to 4.2.2
### Notable changes in 4.2.2
* Includes a fix for `ListDeserializer` silently deserializing a corrupted entry when the input is truncated mid-entry ([KAFKA-20769](https://issues.apache.org/jira/browse/KAFKA-20769)).
* Includes a fix for an exactly-once semantics issue where the checkpoint file written at restoration completion could persist through the `RUNNING` state, causing the state store wipe to be skipped after an unclean crash ([KAFKA-20685](https://issues.apache.org/jira/browse/KAFKA-20685)).
* Includes a fix for a deadlock in `KafkaStreams.removeStreamThread` when it races with a concurrent `REPLACE_THREAD` uncaught-exception handler ([KAFKA-20873](https://issues.apache.org/jira/browse/KAFKA-20873)).
* Includes a fix for consumer group downgrades that could leave the group's on-disk coordinator state permanently unloadable when the group's classic member metadata is very large ([KAFKA-20845](https://issues.apache.org/jira/browse/KAFKA-20845)).
* Includes a fix for the `record-e2e-latency-max` metric only measuring consumption latency instead of the full end-to-end latency (consumption plus processing delay) documented in [KIP-613](https://cwiki.apache.org/confluence/display/KAFKA/KIP-613%3A+Add+end-to-end+latency+metrics+to+Streams) ([KAFKA-14597](https://issues.apache.org/jira/browse/KAFKA-14597)).
* Includes a fix for a high CPU loop on the consumer after a failed re-authentication ([KAFKA-20253](https://issues.apache.org/jira/browse/KAFKA-20253)).
* Includes a fix for consumer groups accepting new classic-protocol members even when `group.consumer.migration.policy=disabled`, which could leave a group permanently stuck in a mixed-protocol state ([KAFKA-20640](https://issues.apache.org/jira/browse/KAFKA-20640)).
* Includes a fix for `AdminClient` APIs routed through the partition-leader cache (`listOffsets`, `deleteRecords`, `describeProducers`, `abortTransaction`) blocking for the full `default.api.timeout.ms` instead of failing fast when a cached leader has left the cluster ([KAFKA-20673](https://issues.apache.org/jira/browse/KAFKA-20673)).
* Bumped jackson-databind ([KAFKA-21004](https://issues.apache.org/jira/browse/KAFKA-21004), [KAFKA-20773](https://issues.apache.org/jira/browse/KAFKA-20773), [KAFKA-20767](https://issues.apache.org/jira/browse/KAFKA-20767)), lz4-java ([KAFKA-20936](https://issues.apache.org/jira/browse/KAFKA-20936)), and jline ([KAFKA-20815](https://issues.apache.org/jira/browse/KAFKA-20815)) to address reported CVEs.
## Upgrading to 4.2.1
### Notable changes in 4.2.1
* Includes a fix for a critical deadlock in the [KIP-932](https://cwiki.apache.org/confluence/x/4hA0Dw) Share Group path ([KAFKA-20505](https://issues.apache.org/jira/browse/KAFKA-20505)).
* Includes a fix for a rolling upgrade issue ([KAFKA-20322](https://issues.apache.org/jira/browse/KAFKA-20322)) that could cause `UnsupportedVersionException` for clusters using transactional producers.
* Includes a fix for a critical broker-side bug in the offline migration code for the Streams Rebalance Protocol ([KAFKA-20254](https://issues.apache.org/jira/browse/KAFKA-20254)). Migrations from classic to streams groups are now safe starting with 4.2.1.
## Upgrading to 4.2.0
### Upgrading Servers to 4.2.0 from any version 3.3.x through 4.1.x
Note: Apache Kafka 4.2 only supports KRaft mode - ZooKeeper mode has been removed. As such, **broker upgrades to 4.2.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.2.x. Clusters in ZooKeeper mode have to be [migrated to KRaft mode](/{version}/operations/kraft/#zookeeper-to-kraft-migration) before they can be upgraded to 4.2.x.
**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.2`
3. Note that cluster metadata downgrade is supported in this version since it has no 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_2_IV1(29, "4.2", "IV1", false)` means this version has no metadata changes). Given your current and target versions, a downgrade is only possible if there are no metadata changes in the versions between.
* If you wish to use share groups in a cluster with fewer than 3 brokers, you must set the broker configurations `share.coordinator.state.topic.replication.factor` and `share.coordinator.state.topic.min.isr` to 1 before you start using share groups. This is because share groups make use of a new internal topic called `__share_group_state` which is automatically created when you first use share groups. In common with the other internal topics, the default configuration uses 3 replicas and requires at least 3 brokers.
### 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 one at a time, rather than as part of an ordered stream.
* The Streams Rebalance Protocol ([KIP-1071](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1071%3A+Streams+Rebalance+Protocol)) is now production-ready for its core feature set. This broker-driven rebalancing system designed specifically for Kafka Streams applications provides faster, more stable rebalances and better observability. For more information about the supported feature set, usage, and migration, please refer to the [Streams developer guide](/{version}/streams/developer-guide/streams-rebalance-protocol). Due to a critical broker-side bug in the offline migration code ([KAFKA-20254](https://issues.apache.org/jira/browse/KAFKA-20254)), we recommend against doing migrations from classic to streams groups in 4.2.0. Newly created streams groups are not impacted. The fix is available in 4.2.1.
* 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` and `kafka-console-producer.sh` (`--consumer.config` and `--producer.config` are deprecated in favor of `--command-config`)
* `kafka-console-share-consumer.sh` (`--consumer-config` is 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. If the configuration is set to true the controller must be shutdown before removing the controller from the voter set to avoid the removed controller to automatically join again. 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.QueuedReplicaToDirAssignments`, `kafka.log.remote:type=RemoteStorageThreadPool.RemoteLogReaderTaskQueueSize`, and `kafka.log.remote:type=RemoteStorageThreadPool.RemoteLogReaderAvgIdlePercent`. For further details, please refer to [KIP-1100](https://cwiki.apache.org/confluence/x/6oqMEw).
* 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](/{version}/configuration/kafka-connect-configs/#connectconfigs_connector.client.config.override.policy) policy. The `PrincipalConnectorClientConfigOverridePolicy` policy is now deprecated and will be removed in Kafka 5.0.0. For further details, please refer to [KIP-1188](https://cwiki.apache.org/confluence/x/2IkvFg).
* 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.2
### Notable changes in 4.1.2
* Includes a fix for the rare Kafka producer bug ([KAFKA-19012](https://issues.apache.org/jira/browse/KAFKA-19012)), in which a record could end up on the incorrect topic.
## Upgrading to 4.1.1
### Notable changes in 4.1.1
* Includes a fix for the critical Kafka Streams bug ([KAFKA-19748](https://issues.apache.org/jira/browse/KAFKA-19748)), solving the memory leak issues that affected users of range scans and certain DSL operators (session windows, sliding windows, stream-stream joins, foreign-key joins).
* Includes a fix for the critical Kafka Streams bug ([KAFKA-19479](https://issues.apache.org/jira/browse/KAFKA-19479)), related to potential data loss.
## 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
The rolling upgrade procedure for 4.1.x is identical to the 4.0 upgrade. Please refer to the [Upgrading Servers to 4.0.x](#upgrading-servers-to-401-from-any-version-33x-through-39x) section for detailed step-by-step instructions.
### 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 one at a time, rather than as part of an ordered stream. To enable share groups, use the `kafka-features.sh` tool to upgrade to `share.version=1`. For more information, please read the [ release notes](https://cwiki.apache.org/confluence/x/CIq3FQ).
* **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](/{version}/operations/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**
* Early Access for the Streams rebalance protocol. Following KIP-848, [KIP-1071](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1071%3A+Streams+Rebalance+Protocol) adds broker side task assignment for Kafka Streams applications.
This feature is in Early Access, disabled by default, and not for production use-cases.
We encourage users to try out the new "streams" group feature in lower environments using "throw away" broker cluster,
and provide early feedback.
## 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](/{version}/getting-started/compatibility) 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](/{version}/operations/kraft/#zookeeper-to-kraft-migration) before they can be upgraded to 4.0.x.
**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 no metadata changes in the versions between.
### 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](/{version}/streams/developer-guide/dsl-api/#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://cwiki.apache.org/confluence/x/K5sODg) for the details.
* 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](/{version}/getting-started/upgrade/#upgrading-servers-to-401-from-any-version-33x-through-39x) 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](/{version}/operations/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. For more information check [here](/{version}/operations/transaction-protocol/).
* 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](/{version}/operations/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.](/{version}/operations/geo-replication-cross-cluster-data-mirroring/).
* 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`](/{version}/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`](/{version}/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](/{version}/streams/upgrade-guide/#streams-api-changes-in-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](/{version}/streams/developer-guide/dsl-api/#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#ConfigurationCompatibility) for more information,
* 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](/{version}/operations/monitoring/#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.