Status

Current state: Under DiscussionApproved

Discussion thread: https://lists.apache.org/thread/mb98kw1qjq2hb0ksj14d3thz3g50x9ck 

Vote thread: https://lists.apache.org/thread/2vlxrnq0ojytw590fhs98f3g2hrwybbl

JIRA:

...

The Kafka node will delete the bootstrap checkpoint if it is not needed. The checkpoint is not needed if the bootstrapping metadata has been committed to the cluster metadata partition. One implementation is for the node to delete the bootstrap checkpoint if it has loaded a non-empty checkpoint from the cluster metadata partition.

Pre-KIP-1170, both brokers and controllers would create this file during formatting. Post-KIP-1170, this file will no longer be written during formatting.

00000000000000000000-0000000000.checkpoint

This checkpoint file is also created by the kafka-storage tool in the __cluster-metadata-0  directory. Now, it will also contain the data that used to be contained in the bootstrap.checkpoint file. It is important to note that the bootstrap records must be less than 8MB of total size if transactions are not supported, since that is the maximum batch size in bytes supported by KRaft.

Pre-KIP-1170, this file was created by KIP-853-enabled controllers who formatted with either --standalone  or --initial-controllers . Post-KIP-1170, this file is created during formatting by controllers. Brokers will not write this file because they cannot write its contents to the metadata log.

RPC

ApiVersionsResponse

There are two fields in the ApiVersionsResponse that are used to describe the finalized feature version of the cluster. There is an existing issue where ApiVersionsResponse reports finalized feature versions even if the state of the cluster metadata partition is not known. Those two fields are documented as follow:

...

Both the Kafka broker and controller nodes will delete the bootstrap.checkpoint file from the metadata log dir if the node has been asked to load a snapshot that contains at least one metadata record.

Kafka Storage Format Command

The kafka-storage format command is responsible for creating the zero checkpoint (00000000000000000000-0000000000.checkpoint). The metadata that is currently written to the bootstrap.checkpoint will instead be written to the zero checkpoint.

Formatting will fail if the metadata log directory already contains the bootstrap.checkpoint or the zero checkpoint. Formatting will be skip if the metadata log dir already contains the bootstrap.checkpoint or the zero checkpoint, and the --ignore-formatted flag is provided.

Compatibility, Deprecation, and Migration Plan

...