Mysql – MaxScale not correctly recognizing new topology when we failover to a new master

failovermaxscaleMySQLmysql-5.6

So I currently have an architecture where we have one master and one slave and read/write splitting in Maxscale. When we fail the slave, Maxscale correctly recognizes it and displays the information accordingly (and does not bring our website down), as well as allow both read and writes on the master. However, when we fail the master, mysqlfailover promotes the slave to the master, but Maxscale does not recognize that the slave is now the master. It does not seem to be granting it write permissions (which causes our website to go down).

When we fail either of the two databases, MySQL recognizes that there has been a change in our topology, but Maxscale does not.

What Maxscale configuration would allow us to correctly have Maxscale recognize this new topology (Slave is now the new master)? Is there an option that we have to select in order to have Maxscale correctly give the proper read/write permissions to the new master?

Since our topology is quite simple, I feel that Maxscale should be smart enough to realize that the new slave is now the master, and adjust accordingly

Best Answer

Turns out the issue was that mysqlfailover was causing a conflict with maxscale. When the master would fail, mysqlfailover would automatically promote a new slave to master. However, when we did this it would cause a conflict with Maxscale (since it usually does it on its own), so it would lose track of which servers were the master and which were the slaves.