Hi Gwen, How about min.isr.replicas property? Is it still valid in the new version 0.9 ?
We could get 3 out of 4 replicas in sync if we set it's value to 3. Correct? Thanks, Prabhjot On Nov 28, 2015 10:20 AM, "Gwen Shapira" <g...@confluent.io> wrote: > In your scenario, you are receiving acks from 3 replicas while it is > possible to have 4 in the ISR. This means that one replica can be up to > 4000 messages (by default) behind others. If a leader crashes, there is 33% > chance this replica will become the new leader, thereby losing up to 4000 > messages. > > acks = all requires all ISR to ack as long as they are in the ISR, > protecting you from this scenario (but leading to high latency if a replica > is hanging and is just about to drop out of the ISR). > > Also, note that in future versions acks > 1 was deprecated, to protect > against such subtle mistakes. > > Gwen > > On Fri, Nov 27, 2015 at 12:28 AM, Andreas Flinck < > andreas.fli...@digitalroute.com> wrote: > > > Hi all > > > > The reason why I need to know is that we have seen an issue when using > > acks=all, forcing us to quickly find an alternative. I leave the issue > out > > of this post, but will probably come back to that! > > > > My question is about acks=all and min.insync.replicas property. Since we > > have found a workaround for an issue by using acks>1 instead of all > > (absolutely no clue why at this moment), I would like to know what > benefit > > you get from e.g. acks=all and min.insync.replicas=3 instead of using > > acks=3 in a 5 broker cluster and replication-factor of 4. To my > > understanding you would get the exact level of durability and security > from > > using either of those settings. However, I suspect this is not quite the > > case from finding hints without proper explanation that acks=all is > > preferred. > > > > > > Regards > > Andreas >
