Hi Justine, Thanks for the comment. Yes, I know we have a configuration min.insync.replicas to avoid this case. And actually, that's my following paragraph is talking about.
Please let me know if you have other comments. Thanks Luke Justine Olshan <jols...@confluent.io.invalid> 於 2023年5月10日 週三 上午1:01 寫道： > Hey Luke, > > I was taking a quick pass over the KIP and saw this line: > > >It looks perfect. But there's a caveat here. Like the doc said, acks=all > will "wait for the *full set of in-sync replicas *to acknowledge the > record", so if there's only 1 replica in in-sync replicas, it will have the > same effect as acks=1 (even though we have replication-factor set to 3). > > I thought we had a configuration min.insync.replicas to avoid this case. > (Typically it is set to two so we need a leader and one follower to > respond.) > > I am curious to understand the proposal more, but just thought I'd share > this as it came up. > > Justine > > On Tue, May 9, 2023 at 9:44 AM Luke Chen <show...@gmail.com> wrote: > > > Hi all, > > > > I'd like to start a discussion for the KIP-926: introducing > > acks=min.insync.replicas config. This KIP is to introduce > > `acks=min.insync.replicas` config value in producer, to improve the write > > throughput and still guarantee high durability. > > > > Please check the link for more detail: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-926%3A+introducing+acks%3Dmin.insync.replicas+config > > > > Any feedback is welcome. > > > > Thank you. > > Luke > > >
