THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Once after starting up, Kafka controllers will register themselves with the active controller. This registration will include information about the endpoints which they possess, as well as information about whether they are ready to perform zk migration, and a randomly generated UUID uniquely identifying the specific incarnation of the controller. The registration will be persisted in the metadata log as hard state.
Periodically, each Each controller will check that the controller registration for its ID is as expected. If it is not, it will re-register. It examines the registration information found in the metadata log. This periodic check is necessary to fix cases where a delayed message from an older incarnation of controller N somehow arrives later than a more recent registration for controller N. Although we expect this to be quite rare, it is possible.
...
| Code Block |
|---|
{
"apiKey": ...,
"type": "request",
"name": "ControllerRegistrationRequest",
"validVersions": "0",
"flexibleVersions": "0+",
"fields": [
{ "name": "ControllerId", "type": "int32", "versions": "0+",
"about": "The controller ID." },
{ "name": "IncarnationId", "type": "uuid", "versions": "0+",
"about": "The controller incarnation ID, which is unique to each process run." },
{ "name": "ZkMigrationReady", "type": "bool", "versions": "0+",
"about": "Set if the required configurations for ZK migration are present." },
{ "name": "Listeners", "type": "[]Listener",
"about": "The listeners of this brokercontroller", "versions": "0+", "fields": [
{ "name": "Name", "type": "string", "versions": "0+", "mapKey": true,
"about": "The name of the endpoint." },
{ "name": "Host", "type": "string", "versions": "0+",
"about": "The hostname." },
{ "name": "Port", "type": "uint16", "versions": "0+",
"about": "The port." },
{ "name": "SecurityProtocol", "type": "int16", "versions": "0+",
"about": "The security protocol." }
]
},
{ "name": "Features", "type": "[]Feature",
"about": "The features on this controller", "versions": "0+", "fields": [
{ "name": "Name", "type": "string", "versions": "0+", "mapKey": true,
"about": "The feature name." },
{ "name": "MinSupportedVersion", "type": "int16", "versions": "0+",
"about": "The minimum supported feature level." },
{ "name": "MaxSupportedVersion", "type": "int16", "versions": "0+",
"about": "The maximum supported feature level." }
]
}
]
} |
...
The following RPCs will now be supported on the controller:
| API | Notes |
|---|---|
| DESCRIBE_CONFIGS | Even on inactive controllers, this can be used to alter the log4j settings dynamically. |
| DESCRIBE_CLUSTER | As described above, DESCRIBE_CLUSTER will be used by AdminClient for bootstrapping. |
| REGISTER_CONTROLLER |
Compatibility, Deprecation, and Migration Plan
...