A shard that has lost a majority does not catch up on its own.

camus admin truncate-to-sealed resumes a write-ahead log shard at its sealed end. Acknowledged batches that were not sealed yet are dropped. The flag is --i-accept-data-loss.

When you need it

A wal produce is acknowledged after a majority of the shard has fsynced the batch. If that majority is gone, the shard cannot confirm the tail. The sealed objects in the bucket are the prefix that is still known. The command moves the shard forward to that prefix and discards the rest.

This is not the three-broker failover on the brokers page. There, one process dies and a remaining majority still commits. Here, the majority of a log shard is gone. Waiting does not rebuild it.

How you run it

camus admin truncate-to-sealed \
  --broker 127.0.0.1:18080 \
  --i-accept-data-loss

The broker flag is the HTTP admin address of a surviving voter, not the Kafka port. The command posts /admin/truncate-to-sealed. Without --i-accept-data-loss it will not do the work. There is no quieter flag that keeps the unsealed acknowledgements, because those bytes are what the lost majority was holding.

After it returns, producers can append again from the sealed end. Consumers should not expect the offsets that were acknowledged and then dropped. Those records are not in the bucket and not on the shard.