A metadata snapshot is a persisted copy of the latest Kafka cluster metadata state reconstructed from the KRaft metadata log. It retains the current state, not the sequence of historical updates that produced it. Controllers create snapshots periodically so the log need not grow indefinitely. section 9.1.1
A controller generates a snapshot locally from its reconstructed log state. Once the snapshot captures earlier updates, the corresponding older log segments can be deleted. During startup or recovery, the controller loads the latest snapshot, then replays log entries written afterward. An in-memory metadata cache serves fast requests; it is distinct from both the persisted snapshot and the log. section 9.1.1
Recovering after a metadata change
Suppose a topic-creation update is recorded after the latest snapshot. On restart, the controller loads that snapshot and replays the later update to restore the current cluster state. It does not need to replay updates already represented in the snapshot. section 9.1.1
Figure 9.4 Metadata records are written to the metadata log. Periodic snapshots capture the latest committed state, which is also maintained in an in-memory cache for rapid access.
Shows the metadata log, periodic snapshots of committed state, and the in-memory cache as three distinct locations for metadata. section 9.1.1
This recovery path is one reason KRaft replaces ZooKeeper-based metadata management: snapshots enable faster metadata restoration. The distinction matters when planning controller operations and investigating startup or failover behavior. section 9.1.4
