Metadata Quorum

A Kafka cluster has three voting controllers. One becomes unavailable, but the other two can still manage metadata. Later, an operator restarts a second controller. The remaining controller is running and has a copy of the metadata, yet it cannot commit new changes by itself.

The difference is the metadata quorum’s majority requirement. Kafka needs enough participating controllers to agree on metadata history, including when a controller fails or the network separates the cluster.

This chapter explains voting membership, failure tolerance, controller placement, and how to inspect quorum health. The examples assume a KRaft-based cluster. Majority calculations use a stable voting membership; membership changes require their own coordinated procedure.