Hi Luke, Thank you for your response.
Our testing confirmed your note: when we ensured that none of the nodes being added to the quorum had any metadata lag, the migration completed without issues. Regards, Benson From: Luke Chen <[email protected]> Date: Wednesday, September 23, 2026 at 15:29 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Zhang, Vinson <[email protected]>; Yang, Yuanhao <[email protected]>; Zhang, Reggie <[email protected]>; Xiong, Benson <[email protected]> Subject: Re: Is KRaft dedicated controller(static quorum) → combined mode migration supported in kafka 3.9.1 Hi Benson, Yes, your steps look correct to me. The migration to combined nodes should work. Just be noted, if you want to add some lagged nodes into the voters, it might impact the quorum because it needs the majority of nodes to be caught up. Thank you, Luke On Wed, Sep 23, 2026 at 1:55 PM Xiong, Benson via users <[email protected]<mailto:[email protected]>> wrote: + kafka dev group... From: Xiong, Benson via users <[email protected]<mailto:[email protected]>> Date: Tuesday, September 22, 2026 at 17:56 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: Zhang, Vinson <[email protected]<mailto:[email protected]>>; Yang, Yuanhao <[email protected]<mailto:[email protected]>>; Zhang, Reggie <[email protected]<mailto:[email protected]>>; Xiong, Benson <[email protected]<mailto:[email protected]>> 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
