...

KIP-853: KRaft Controller Membership Changes added support for bootstrapping the KRaft state while

This KIP unifies these two checkpoints by moving the starting metadata from bootstrap.checkpoint to the zero checkpoint. The main advantage of using the zero checkpoint is that it integrates with the rest of the checkpoint mechanisms like checkpoint loading (RaftClient.Listener#handleLoadSnapshot) and checkpoint deletion introduced in KIP-630: Kafka Raft Snapshot. For example, not deleting the bootstrap.checkpoint has cause issues with Kafka startup logic as documented in

Currently, these two snapshots that handle bootstrapping metadata can be viewed as "logically separate," and this KIP seeks to unify them under the zero checkpoint in KRaft.

• Pre-KIP-1170, the zero checkpoint only contains KRaft control records that follow the semantics of KIP-630: Kafka Raft Snapshot (The control records SnapshotHeaderRecord  and SnapshotFooterRecord  are not a concept in the bootstrap.checkpoint). Other KRaft control records include the kraft.version  level and the starting voter set.
• Pre-KIP-1170, the bootstrap checkpoint can contain feature level mappings (i.e. metadata.version=24,transaction.version=1,etc.) and SCRAM credentials, and this mapping on disk is read by the QuorumController  when it becomes leader. The active QuorumController  attempts to write the bootstrap metadata records in a transaction if transactions are supported, or in a single atomic batch. From the perspective of KRaft, the contents of the bootstrap.checkpoint are "data" records, not control records.

Public Interfaces

bootstrap.checkpoint

The bootstrap.checkpoint file is created by the kafka-storage tool in the metadata. log.dir. This file will be deprecated. The kafka-storage tool will not create this file any more and will instead write metadata record to the zero checkpoint in the cluster metadata partition.

The kafka-storage tool will delete the bootstrap.checkpoint file if it already existingexists. This is done to make sure that the metadata state is not contained in both bootstrap.checkpoint and the zero checkpoint.

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. 

Proposed Changes

Controller

When the controller handles RaftClient.Listener#handleLoadSnapshot if the snapshot id has an epoch of 0 and an a base offset of 0, the controller will consider these records as the bootstrapping records. The controller will rewrite bootstrap records to the log if they have been successfully written in the past. If the controller doesn't load a snapshot at epoch 0 and offset 0, the controller will load the bootstrap.checkpoint and rewrite the bootstrapping record to the cluster metadata partition.

...

1. bootstrap.checkpoint exist with metadata records and the zero checkpoint doesn't exists - In this case the controller will behave as it does today. The controller will be able to identify this case because RaftClient.Listener#handleLoadSnapshot won't ask to load the zero snapshot.
2. bootstrap.checkpoint exist with metadata records and the zero checkpoint exists but doesn't contain any metadata records - In this case the controller will behave as it does today. The controller will be able to identify this czse case because RaftClient.Listener#handleLoadSnapshot will ask to load the zero checkpoint but it will be empty, no metadata records.
3. bootstrap.checkpoint doesn't exist and the zero checkpoint exists with metadata records - In this case the controller will use the zero checkpoint a

...