THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
This KIP defines the behavior and set of new APIs for the “bridge release” as first mentioned in KIP-500.
Public Interfaces
Metrics
| MBean name | Description |
|---|---|
| kafka.server:type=KafkaServer,name=MigrationState | An enumeration of the possible migration states the broker is in. Each broker reports this. All migration states except "MigrationReady" are able to be reported by the brokers. |
| kafka.controller:type=KafkaController,name=MigrationState | An enumeration of the possible migration states the cluster can be in. This is only reported by the active controller. The "ZooKeeper" and "MigrationEligible" states are reported by the ZK controller, while the remaining states are reported by the KRaft controller. |
| kafka.controller:type=KafkaController,name=ZooKeeperWriteBehindLag | The amount of lag in records that ZooKeeper is behind relative to the highest committed record in the metadata log. This metric will only be reported by the active KRaft controller. |
New metadata.version (IBP)
A new metadata.version will be used for a few things in this design.
...
The controller will use a bounded write-behind approach for ZooKeeper updates. As we commit records to KRaft, we will asynchronously write data back to ZooKeeper. The number of pending ZK records will be bounded so that we can avoid excessive lag between the KRaft and ZooKeeper states.
This dual write approach ensures that any metadata seen in ZK will also be committed to KRaft.
ZK Broker RPCs
In order to support brokers that are still running in ZK mode, the KRaft controller will need to send out a few additional RPCs to keep things working in the broker.
...
Once the data has been migrated and the cluster is the MigrationActive MigrationActive or MigrationFinished state, the KRaft controller may fail. If this happens, the Raft layer will elect a new leader which update the "/controller" and "/controller_epoch" ZNodes and take over the controller leadership as usual.
...