Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Not a Bug
-
10.3(EOL), 10.4(EOL), 10.5, 10.6
Description
The DISABLE ON SLAVE option sets the status SLAVESIDE_DISABLED on master and slaves EVENTS
This appears to be a bug that has been around for some time and/or a leftover from the past with a misleading status for an EVENT on a master node.
I can't think of a case were changing an EVENT to DISABLE ON SLAVE would be useful, since by default CREATE EVENT sets the status on the slaves to SLAVESIDE_DISABLED.
"DISABLE ON SLAVE" used with CREATE or ALTER EVENT should either:
A) NOT change the EVENT status on the master node to SLAVESIDE_DISABLED and keeping current ENABLED or DISABLED status on master. Or act like the DISABLE option and keep the event status on the slaves to SLAVESIDE_DISABLED.
Or
B) Remove the DISABLE ON SLAVE option altogether from CREATE or ALTER EVENT. DISABLE can be used instead. Having the status SLAVESIDE_DISABLED on an EVENT on the master node is misleading.
Also see MDEV-12284
An event can be in one of the tree states: A, B, and C. And there's an ALTER EVENT statement that allows to change the state. It would be very weird if ALTER EVENT ... A would change the state to A, ALTER EVENT ... B would change the state to B, while ALTER EVENT ... C would change the state to A. It'd be a very non-intuitive and unexpected behavior.
Another reason for keeping the current behavior, besides consistency, is mysqldump. One may want to do perform a backup on a slave and later restore it exactly as it was, including events in the SLAVESIDE_DISABLED state. Meaning CREATE EVENT ... DISABLE ON SLAVE should work as it does now.