Bug #85254 mysqlfailover 1.6.5 stop breaks replication
Submitted: 1 Mar 2017 15:06 Modified: 6 Mar 2017 9:11
Reporter: Andrew Mahoney Email Updates:
Status: Verified Impact on me:
Category:MySQL Utilities Severity:S2 (Serious)
Version:1.6.5 OS:Any
Assigned to: CPU Architecture:Any

[1 Mar 2017 15:06] Andrew Mahoney
Fix for bug #20524886 "The mysqlfailover utility did not remove the failover_console table correctly on exit when run with the --daemon=start option." removes the table/entry with the binlog enabled when it is created with it disabled.

This breaks replication with 
Last_SQL_Errno: 1146
Last_SQL_Error: Error executing row event: 'Table 'mysql.failover_console' doesn't exist'

I was running this against Percona XtraDB server 5.6 in a test environment, however I can't see how this behaviour would be any different in Oracle MySQL community edition.
What seems to be an inconsistency in how it is added to the master and how it is removed would suggest this is not correct.

How to repeat:

Start mysqlfailover 1.6.5 in daemon mode against a replication topology and then stop it using --daemon=stop.

Check the status of the slaves, using "show slave status\G"

Suggested fix:
Disable binlog before clearing registration.

mysql/utilities/command/failover_daemon.py.orig mysql/utilities/command/failover_daemon.py
--- mysql/utilities/command/failover_daemon.py.orig	2017-03-01 14:08:43.712417373 +0000
+++ mysql/utilities/command/failover_daemon.py	2017-03-01 14:09:39.486417373 +0000
@@ -690,8 +690,10 @@
         if not self.master.is_alive():
+            self.master.toggle_binlog("DISABLE")
+            self.master.toggle_binlog("ENABLE")
             self._report("Master entry in the failove
                          " table was deleted.", logging.INFO, False)
[6 Mar 2017 9:11] MySQL Verification Team

Thanks for your bug report, verified as reported.

all best
Bogdan Kecman
[9 Mar 2017 20:29] Owen Owen
I ran into the same issue.
[24 Mar 2017 5:53] Erik Knudtson
We ran into this issue as well.
[9 Jul 2018 6:55] MySQL Verification Team
Bug #91562 marked as duplicate of this one