2
votes

I am seeing a different behavior with acks all. From the documentation,

acks=all This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting.

I had a 3 broker setup and a topic with replication factor 3 .My understaning about the above statement is , the leader will wait if any of the brokers is down( as it *will wait for ISR to acknowledge * the record. But, to my surprise, it is the not the case, the message is produced and consumed by the consumer.

Is it that, it is not honored in this case ?

2

2 Answers

2
votes

The acks = all is honored in relation to the min.insync.replicas broker parameter that by default is 1; this is the reason why you see your producer sending without problems and the consumer consuming as well. In your case, with 3 brokers, if you want the producer be able to send only when ALL of them are running, you have to set min.insync.replicas=3 as well.

0
votes

Looks like this need to be interpreted along with min.insync.replicas .

When a producer sets acks to "all" (or "-1"), min.insync.replicas specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful. If this minimum cannot be met, then the producer will raise an exception (either NotEnoughReplicas or NotEnoughReplicasAfterAppend). When used together, min.insync.replicas and acks allow you to enforce greater durability guarantees.