morgando commented on code in PR #920:
URL: https://github.com/apache/kafka-site/pull/920#discussion_r4170189298
##########
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:
I agree that it is good to mention that the check/update epoch step should
be done quickly -- made that change :)
To optimize for minimizing the no-controller window, we could maybe do this:
1. deprovision kraft quorum.
2. delete /controller
3. compare epochs. if kraft epoch > zk epoch, bump zk epoch and delete
/controller to trigger another election.
4. delete /migration
5. ...
This seems like essentially what you did to recover from
https://issues.apache.org/jira/browse/KAFKA-20488. It would minimize the
no-controller window, at the cost of potentially allowing a low-epoch
controller to become active briefly in rare cases, with a documented recovery
strategy.
--
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]
