You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Youssef Ismail (Jira)" <ji...@apache.org> on 2026/08/26 14:42:00 UTC
[jira] [Created] (KAFKA-20989) KRaft dual-write does not clean up ZooKeeper config and ACL notification znodes
Youssef Ismail created KAFKA-20989:
--------------------------------------
Summary: KRaft dual-write does not clean up ZooKeeper config and ACL notification znodes
Key: KAFKA-20989
URL: https://issues.apache.org/jira/browse/KAFKA-20989
Project: Kafka
Issue Type: Bug
Components: kraft
Affects Versions: 3.9.1
Reporter: Youssef Ismail
During ZooKeeper-to-KRaft migration, the KRaft controller creates persistent sequential notifications for [config changes|https://github.com/apache/kafka/blob/3.9.1/core/src/main/scala/kafka/zk/migration/ZkConfigMigrationClient.scala#L352-L357] and [ACL changes|https://github.com/apache/kafka/blob/3.9.1/core/src/main/scala/kafka/zk/migration/ZkAclMigrationClient.scala#L41-L44].
These nodes are normally deleted after 15 minutes by [{{ZkNodeChangeNotificationListener}}|https://github.com/apache/kafka/blob/3.9.1/core/src/main/scala/kafka/common/ZkNodeChangeNotificationListener.scala#L125-L140], which is started by [ZooKeeper-mode brokers|https://github.com/apache/kafka/blob/3.9.1/core/src/main/scala/kafka/server/KafkaServer.scala#L631-L633].
Once all brokers enter KRaft mode in dual-write phase no cleanup listener remains, while the [migration controller continues dual-writing|https://github.com/apache/kafka/blob/3.9.1/core/src/main/scala/kafka/server/ControllerServer.scala#L284-L314]. Consequently, {{{}/config/changes{}}}, {{{}/kafka-acl-changes{}}}, and {{/kafka-acl-extended-changes}} keep growing without deletion.
Normally if the migration happens quickly this shouldn't be an issue However we want to let our clusters bake for some time in this phase before finalizing the migration which causes the backlog.
This can increase ZooKeeper load and eventually make {{getChildren}} exceed {{{}jute.maxbuffer{}}}, potentially impairing rollback.
I think the simplest solution is to have the migration controller run an equivalent cleanup while migration mode is enabled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)