Page History

...

• If meta.properties does not exist and the node is a broker/observer controller, write meta.properties V2 with node.id  and directory.id
  • This means either this node skipped formatting, or the file/disk was lost
• If meta.properties does not exist exists and the node is a bootstrap controller, throw a runtime exceptionThis is v1, do the same behavior validations as we do today in kafka today
• If meta.properties exists without a cluster.id and is V2, it will be discovered later (described below)
  • One correctness invariant of this feature is that updating the cluster.id in-memory must occur after persisting it to meta.properties.
• If meta.properties exists with a cluster.id, kafka behaves as it does today:
  • The node assumes it to be correct and passes it to KRaft
  • If this ID doesn't match the KRaft leader's ID, the leader will reject requests from the node
• If a broker/observer controller has already written a cluster id to its meta.properties, either from formatting or discovering it from the cluster metadata, it is impossible for it to learn of another cluster id via Fetch/FetchSnapshot.
  • For the broker (with clusterid = X) to receive a non-error FetchResponse with metadata records (which would be the only way to learn of a different ClusterIdRecord), the KRaft leader (clusterid = Y) must either receive a request without clusterid, or a request whose clusterid is Y. The broker fulfills neither of these conditions.
  • This case could happen when bootstrap endpoints point to the wrong cluster during restart of a node. KRaft's own clusterid checks would mean startup of this node would time out and shut down the node because it is not able to contact the quorum of another cluster.

...