Kafka recovery and compaction
Kafka Broker state contains expensive derived structures: producer epochs and sequences, open transactions, aborted ranges, leader epochs, virtual segments, and indexes. Nereus checkpoints make restart bounded without replacing Kafka’s own metadata authority.
NKC1 recovery checkpoint
The immutable checkpoint contains a stable-head anchor, producer/transaction state, virtual segment/index state, exact coverage, and checksums. A Broker restart:
- Reads the current Nereus head.
- Chooses a checkpoint that does not lead the head.
- Verifies the object, root, and binding reference.
- Hydrates the checkpoint boundary.
- Replays the committed tail to the current head.
- Applies current durable trim.
- Publishes the partition readable/writable.
The checkpoint accelerates replay; it cannot rewrite the stream head or internal-topic coordinator truth.
Mandatory compacted coverage
__consumer_offsets and __transaction_state have key-compacted semantics. If a coordinator has
activated a compacted generation set, a missing or corrupt set cannot fall back to an ordinary
COMMITTED generation: old compacted-away values could be resurrected.
The activation constraint therefore verifies HEAD, CRC, ETag, full SHA, exact generation-set identity, and coverage. Corruption quarantines the set and blocks coordinator open until the exact bytes/root/index are repaired and coverage is activated again.
DeleteRecords and retention
Kafka’s logical deletion boundary is derived from DeleteRecords, retention time/bytes,
cleanup.policy, HW/segment rules, and the stock retention oracle. A consumer-group committed
offset is not a retention floor.
The durable sequence is:
compute new logStartOffset
-> publish pre-trim NKC1 checkpoint
-> StreamStorage.trim(newStart)
-> verify durable trim
-> update binding observed log start and local canonical state
-> run physical GC asynchronously
If the trim response is lost, a fresh Broker reloads head, trim, and checkpoint. Retrying the same target is idempotent and must not create a second checkpoint or trim mutation.
Kafka key compaction
Key compaction is semantic view generation, not a local segment swap:
- Freeze closed virtual segments, HW, LSO, cleanup policy, and exact source generations.
- Scan once to choose key winners, tombstones, and transaction/control handling.
- Re-read the exact source set and emit sparse
NTC2rows. - Guarded-PUT and fully verify the output.
- Publish a
TOPIC_COMPACTEDgeneration. - Activate gap-free compacted coverage in the binding.
- Read the compacted prefix from that view while the active tail remains in
COMMITTED.
Tasks, plans, and staging files are workflow state. Final generation publication and binding coverage activation decide what Fetch may use; a higher generation alone is not enough.