kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gwen Shapira <g...@confluent.io>
Subject Re: What is the benefit of using acks=all and minover e.g. acks=3
Date Sat, 28 Nov 2015 04:49:54 GMT
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

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.


On Fri, Nov 27, 2015 at 12:28 AM, Andreas Flinck <
andreas.flinck@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message