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 < users@kafka.apache.org> wrote: > + 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