+ kafka dev group... From: Xiong, Benson via users <users@kafka.apache.org> Date: Tuesday, September 22, 2026 at 17:56 To: users@kafka.apache.org <users@kafka.apache.org> Cc: Zhang, Vinson <vinson.zhang@sap.com>; Yang, Yuanhao <yuanhao.yang@sap.com>; Zhang, Reggie <reggie.zhang@sap.com>; Xiong, Benson <benson.xiong01@sap.com> Subject: Is KRaft dedicated controller(static quorum) → combined mode migration supported in kafka 3.9.1 Hi Kafka community, I’d like to confirm whether an in-place KRaft topology change from dedicated controllers(static quorum) to combined broker/controller nodes is officially supported? For example: Current topology: Controllers: 101,102,103 with process.roles=controller Brokers: 1,2,3 with process. Roles=broker Current quorum: controller.quorum.voters=101@host1:9093,102@host2:9093,103@host3:9093 Target topology: Nodes: 1,2,3 with process.roles=broker, controller Target quorum: controller.quorum.voters=1@host1:9093,2@host2:9093,3@host3:9093 I could not find this topology-change path documented in the Apache Kafka docs, so I’d like to confirm: 1. Is this migration path officially supported? 2. Is it safe to change broker nodes from `process.roles=broker` to `process.roles=broker,controller` without wiping/reformatting storage? Also without any impact to the data state(data integrity and their pub sub state) in kafka? 3. Is replacing the controller voter set from `101,102,103` to `1,2,3` supported if the whole cluster is fully stopped first? I tested this locally with Kafka 3.9.1. 1. Before the change, brokers `1,2,3` appeared as metadata-log observers. 2. Stop the cluster, changing the three broker configs to `process.roles=broker,controller`, and updating `controller.quorum.voters` to `1,2,3` 3. Start the cluster successfully. The new quorum became `1,2,3`, and topic operations worked. I also tested with one future voter(say broker 3) having metadata lag. After repeating same 2, 3 steps, the new combined-mode quorum still formed and the lagging node caught up after the new quorum started, no data lost in kafka topics, pub sub worked out okay. NOTE: the old and new voter sets have no overlapping majority: old voters: 101,102,103 new voters: 1,2,3 Could someone help to confirm whether this is a supported/recommended procedure? If yes, is it for production deployment? Or only an unsafe/undocumented behavior that happened to work in this local test? Best Regards, Benson
Comments
Post a Comment