Overview
In KRaft the cluster metadata lives in an internal single-partition topic, __cluster_metadata, whose replication is managed by Raft. Changes such as broker registration, topic creation and partition changes are appended to it as metadata records, and the active controller, the quorum leader, is the one that appends them. Brokers fetch the metadata log from the active controller and apply the changes in order. The controllers store all the cluster's metadata in memory and on disk.
Key configuration
metadata.log.dir — where the metadata log is stored; if it is not set, the first log.dirs directory is used
metadata.log.segment.bytes=1073741824 — default, 1 GiB: the maximum size of a single metadata log fileProduction tip
Check yourself
How do brokers learn about metadata changes in KRaft mode?
Sources
- KIP-631: The Quorum-based Kafka Controller (opens in a new tab)
- KIP-595: A Raft Protocol for the Metadata Quorum (opens in a new tab)
- KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum (opens in a new tab)
- KRaft operations (4.2 documentation) (opens in a new tab)
- Broker configs (4.2 documentation) (opens in a new tab)
- MetadataQuorumCommand.java (4.2 source) (opens in a new tab)
Checked against Kafka 4.2 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.