Table of Contents

Status

Current state: Under Discussion

...

1. Remove broker.id configuration: The BROKER_ID_CONFIG will be removed from ServerConfigs. Setting it will result in an unknown configuration warningbe silently ignored.
2. Remove synonym logic: Remove the broker.id/node.id synonym handling from AbstractKafkaConfig.populateSynonyms().
3. Retain internal brokerId() accessor: The brokerId() method will continue to exist for internal use, delegating to nodeId().

...

Note: In the 5.0 column, "ignored" means broker.id is treated as an unrecognized configuration , which logs a standard unknown config warningand silently ignored. The Kafka server does not log warnings for unrecognized configurations.

Compatibility, Deprecation, and Migration Plan

...

• broker.id is no longer recognized and is silently ignored with an unknown config warning.
• Setting only broker.id without node.id results in a ConfigException.

...

Throw ConfigException when broker.id is set in 5.0

Instead of silently ignoring broker.id as an unrecognized configuration in 5.0, we could explicitly throw a ConfigException. However, this would force users to update their configuration files before upgrading, making the upgrade process more disruptive. Ignoring Silently ignoring unrecognized configurations is consistent with how other removed configurations are handled in Kafka.

Log a customized warning when broker.id is set in 5.0

We could add special-case logic to detect and warn users that broker.id has been removed. However, the Kafka server does not log warnings for unrecognized configurations, and adding a one-off check just for broker.id would be inconsistent with how other removed configurations are handled. The deprecation warning in Phase 1 already provides sufficient notice for users to migrate.

References

• KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum
• KIP-631: The Quorum-based Kafka Controller