Thanks Luke, Just a follow up question, is it possible to migrate using dual-mode for the broker/controller? I.e. with `process.roles=broker,controller` set?
Specifically in Kubernetes? Or is the my understanding correct that the correct order of the migration in kube would be: 1. Start standalone new KRaft mode controller (1 or 3 instances) with relevant config values set 2. Run the kafka-storage.sh script on the new controller(s) with access to the brokers data directories (???) The docs are unclear as to when/if this needs to be done 3. Reconfigure and restart the brokers 4. Restart the controller(s) with the migration configuration removed 5. Remove ZK instances Please let me know if this understanding is correct and/or if there is any other documentation on how to properly migrate when running on Kubernetes! Thanks in advance, Upesh Upesh Desai| Senior Software Developer ude...@itrsgroup.com ITRS From: Luke Chen <show...@gmail.com> Date: Friday, July 5, 2024 at 3:41 AM To: ude...@itrsgroup.com.invalid <ude...@itrsgroup.com.invalid> Cc: users <users@kafka.apache.org> Subject: Re: KRaft Migration Prod Ready? Hi Upesh, Yes, it's supported. The doc will be updated soon (after v3.8.0 released). Thanks. Luke On Wed, Jul 3, 2024 at 6:02 AM Upesh Desai <ude...@itrsgroup.com.invalid> wrote: > Hello, > > > > We have been a bit confused as to if KRaft migration from ZooKeeper is > production ready? It seems that the Kafka docs still indicate it is NOT > ready: https://kafka.apache.org/documentation/#kraft_zk_migration > > > > But other sites such as Confluent and Strimzi do say it is supported: > - https://strimzi.io/blog/2024/03/21/kraft-migration/ > > - https://www.confluent.io/blog/introducing-apache-kafka-3-6/ > > > > Thanks in advance! > Upesh Desai > | > Senior Software Developer > ude...@itrsgroup.com > ITRS > <https://www.itrsgroup.com/> > Internet communications are not secure and therefore the ITRS Group does > not accept legal responsibility for the contents of this message. Any view > or opinions presented are solely those of the author and do not necessarily > represent those of the ITRS Group unless otherwise specifically stated. > [itrs.email.signature] >
