KIP-841 improves the topic partitions’ availability during clean shutdown. KIP-841: Fenced replicas should not be allowed to join the ISR in KRaft In order to facilitate upgrades of Apache Kafka in KRaft mode, we need the ability to upgrade controllers and brokers while holding back the use of new RPCs and record formats until the whole cluster has been upgraded. KIP-778 allows the upgrade of KRaft clusters without the need for the infamous “double roll”. The bridge release is the release that would allow the migration of Apache Kafka clusters from ZK mode to KRaft mode. KIP-833 also marks 3.5.0 as the bridge release. KIP-833 marks KRaft as production-ready for new clusters in the Apache Kafka 3.3 release. Kafka Broker, Controller, Producer, Consumer and Admin Client KIP-833: Mark KRaft as Production Ready For more information on these features and proposed KRaft timelines, read KIP-833. There are some features that are currently supported by Apache ZooKeeper (ZK) mode that are not yet supported by KRaft mode.

The 3.3 release now marks KRaft mode as production ready for new clusters only. It also eliminates the need to run an Apache ZooKeeper™ cluster alongside every Apache Kafka cluster. This new mode, called KRaft mode, improves partition scalability and resiliency while simplifying deployments of Apache Kafka. For a full list of changes, be sure to check the 3.3.0 and 3.3.1 release notes.įor several years, the Apache Kafka community has been developing a new way to run Apache Kafka with self-managed metadata. This blog post will highlight some of the more prominent features. The 3.3 release contains many new features and improvements. We are proud to announce the release of Apache Kafka® 3.3 on behalf of the Apache Kafka community.

Kafka 1927