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
