mwesterby commented on code in PR #920: URL: https://github.com/apache/kafka-site/pull/920#discussion_r4146437930
########## content/en/39/operations/kraft.md: ########## @@ -486,9 +486,8 @@ Enter Migration Mode on the brokers <td> - - * Using `zookeeper-shell.sh`, compare the ZooKeeper controller epoch (`get /controller_epoch`) to the KRaft controller epoch (the `kraft_controller_epoch` field in `get /migration`). If the KRaft epoch is higher, run `set /controller_epoch <value>` (where `<value>` exceeds the KRaft epoch) to ensure the ZooKeeper controller will start with a higher epoch after reverting. * Deprovision the KRaft controller quorum. + * Using `zookeeper-shell.sh`, compare the ZooKeeper controller epoch (`get /controller_epoch`) to the KRaft controller epoch (the `kraft_controller_epoch` field in `get /migration`). If the KRaft epoch is higher, run `set /controller_epoch <value>` (where `<value>` exceeds the KRaft epoch) to ensure the ZooKeeper controller will start with a higher epoch after reverting. Review Comment: My initial reasoning for comparing and updating the epochs before deprovisioning the quorum was to minimise the time the cluster has no controller, i.e. we could run `delete /controller` immediately after the quorum is gone. This seems like the right change though. Doing the check after the controllers have been deprovisoned is the only way to guarantee the new epoch exceeds the `kraft_controller_epoch` and prevents the edge case it advanced past what you set. Maybe we should update the notes column to explicitly mention the check/update epoch step should be done quickly too, alongside the delete /controller step in there? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
