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
