How MaxScale Handles MySQL Slave Failures and Automatic Failover

Previously we introduced that MaxScale can achieve MySQL read/write splitting and load balancing. This article explores how MaxScale reacts when slave servers fail.

Single Slave Failure

Environment: three database servers in a master‑slave‑slave topology named master, slave1, and slave2.

Enable detailed logging by editing /etc/maxscale.cnf and adding:

log_info=1
logdir=/tmp/

Restart MaxScale after the change.

Stop replication on slave2: mysql> stop slave; MaxScale status shows that slave2 is lost, and the log contains:

2016-08-15 12:26:02   notice : Server changed state: slave2 [172.17.0.4:3306]: lost_slave

All client queries are automatically routed to slave1 (see screenshot).

Restart slave2: mysql> start slave; MaxScale detects the new slave:

2016-08-15 12:32:36   notice : Server changed state: slave2 [172.17.0.4:3306]: new_slave

Client queries are now distributed between slave1 and slave2, confirming that MaxScale transparently handles a single‑slave outage.

All Slaves Failure

Stop replication on both slave1 and slave2: mysql> stop slave; MaxScale status shows that the master and both slaves are lost. The log records:

2016-08-15 12:44:11   notice : Server changed state: master [172.17.0.2:3306]: lost_master
2016-08-15 12:44:11   notice : Server changed state: slave1 [172.17.0.3:3306]: lost_slave
2016-08-15 12:44:11   notice : Server changed state: slave2 [172.17.0.4:3306]: lost_slave
2016-08-15 12:44:11   error : No Master can be determined. Last known was 172.17.0.2:3306

Client connections to MaxScale fail because no master can be identified.

To keep the master usable when all slaves are down, edit /etc/maxscale.cnf and add the following under the [MySQL Monitor] section: detect_stale_master=true Restart MaxScale. After stopping both slaves again, MaxScale retains the master in a stable state, and client requests are routed to the master, ensuring continued service.

When the slaves are started again, MaxScale automatically restores the normal read‑write distribution.

Conclusion

The tests show that MaxScale transparently handles partial slave failures, and with a simple configuration change it can also maintain service when all slaves are unavailable by keeping the master active.