DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
- The default value of
-1forbroker.idis effectively unused in KRaft mode. Ifnode.idis set, the synonym mechanism overwritesbroker.idwith the value ofnode.id. If neither is set,node.idvalidation fails with aConfigExceptionbefore the default is ever used. - The documentation describes
node.idas required in KRaft mode, but it can currently be omitted ifbroker.idis set, because the synonym mechanism automatically populatesnode.idfrombroker.id. After the removal in 5.0,node.idmust be explicitly set.
The behavior is the same for all process.roles (broker, controller, or combined). No changes to public APIs, network protocols, metrics, or command-line tools.
...
The following table summarizes the expected behavior for each configuration scenario across version ranges:
Configuration | Current (4.0 ~ 4.2 (Current) | Phase 1: Deprecated (4.3 ~ 4.x (Deprecated) | Phase 2: Removed (5.0 (Removed) |
|---|---|---|---|
Only | Valid | Valid | Valid |
Only | Valid; | Valid + |
|
Both set, same value | Valid | Valid + | Valid; |
Both set, different values |
|
| Valid; |
Neither set |
|
|
|
...
Users should replace broker.id with node.id in their server configuration. If both are configured, simply remove broker.id.
Downgrade Considerations
Downgrading from 5.0 to 4.x is safe as long as the same configuration file is used — any config that was valid on 4.x before the upgrade remains valid after the rollback. The only edge case is if broker.id and node.id are set to different values on a 5.0 binary (where broker.id is ignored) and then downgraded to 4.x, which would result in a ConfigException. In practice, this cannot happen if the config was originally used on 4.x.
Test Plan
Phase 1: Deprecation (Apache Kafka 4.3)
...
broker.idis no longer recognized and is ignored with an unknown config warning.- Setting only
broker.idwithoutnode.idresults in aConfigException.
Rejected Alternatives
Throw ConfigException when broker.id is set in 5.0
Instead of 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 unrecognized configurations is consistent with how other removed configurations are handled in KafkaNone.