Hi Calvin, Thank you for the KIP. I have a similar question -- we need to support rolling upgrades (when we have some old brokers and some new brokers), so there could be combinations of old leader - new follower, new leader - old follower, new leader - old controller, old leader - new controller. Could you elaborate on the behavior during rolls in the Compatibility section?
Also for compatibility it's probably going to be easier to just add a new array of epochs in addition to the existing array of broker ids, instead of removing one field and adding another. The KIP mentions that we would explicitly do something special in ZK mode in order to not implement new functionality. I think it may be easier to implement functionality for both ZK and KRraft mode than adding code to disable it in ZK mode. -Artem On Tue, Feb 7, 2023 at 4:58 PM Jun Rao <j...@confluent.io.invalid> wrote: > Hi, Calvin, > > Thanks for the KIP. Looks good to me overall. > > Since this KIP changes the inter-broker protocol, should we bump up the > metadata version (the equivalent of IBP) during upgrade? > > Jun > > > On Fri, Feb 3, 2023 at 10:55 AM Calvin Liu <ca...@confluent.io.invalid> > wrote: > > > Hi everyone, > > I'd like to discuss the fix for the broker reboot data loss KAFKA-14139 > > <https://issues.apache.org/jira/browse/KAFKA-14139>. > > It changes the Fetch and AlterPartition requests to include the broker > > epochs. Then the controller can use these epochs to help reject the stale > > AlterPartition request. > > Please take a look. Thanks! > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-903%3A+Replicas+with+stale+broker+epoch+should+not+be+allowed+to+join+the+ISR > > >
