Two ways to acknowledge a produce.
wal answers as soon as a disk majority has the batch. r2 answers only after the object is stored and the offset is committed. The cluster default is wal.
| Mode | When a produce is acknowledged |
|---|---|
wal, the default |
A majority of the WAL shard has fsynced the batch. The upload to the bucket follows, and the write-ahead log is truncated once that range is sealed. |
r2 |
The batch is in the bucket and the metadata group has committed its offsets. The broker keeps no log bytes. |
Why wal is the default
Object storage is the right place for the log you keep. It is a poor place to wait on every acknowledgement. wal keeps a few seconds of log on local disk so the producer is not limited by bucket latency. The bytes are still uploaded. After the seal, the local copy of that range can go.
A broker can accept that first acknowledgement without a bucket. The upload that should follow will fail. If you need the sealed log, create the bucket first. The bucket page is the local way to do that.
When to choose r2
Choose r2 when a broker disk is not an acceptable copy of the log, even for a few seconds. The producer waits for the round trip to the bucket and for the metadata commit. A restarted broker has nothing to replay from local disk. The log it serves is the objects already sealed.
How you set it
Set durability.mode on the topic when you create it. The value is wal or r2. Topics that do not set it inherit CAMUS_DEFAULT_DURABILITY, which is wal unless you change the environment.
The decision is written down in ADR 0005. acks=1 does not weaken either mode. It uses the same barrier as acks=all. acks=0 does not wait, and the batch may be lost.