The above example illustrates how to start the mysqlfailover utility to check the health of the replication topology and shows the displayed output when failover occurs.

Basically, we simply need to specify the master's connection with the --master option, the list of slaves with the --slaves option and the replication user (login and password) using the --rpl-user options. In alternative to the --slaves options, one can use the --discover-slaves-login specifying a user and password (or login-path) to connect to the slaves and the utility will attempt to discover all the slaves connected with the master using the specified login. For the above example, '--discover-slaves-login=root' could be used.

The --discover-slaves-login can be very handy especially if there is a huge number of slaves in the topology, but bear in mind that the explicit specification of slaves is safer and that discovery can fail to find some servers. In particular, it is important to note that in order for slaves to be discovered, they must be started with the '--report-host' and '--report-port' options with a appropriate values and they must be correctly connected to the master (I/O thread running) otherwise discovery will fail.

It is also recommended to use the --log options to specify a file to register all events, warning and errors. This is useful to keep a record of what happened, for example to later determine when failover occurred and if the process occurred without any errors.

An important matter to discuss is the order in which the server are select as candidates for failover. No distinction is made in terms of the number of transaction to select the most up-to-date slave to become the new master. The reason is very simple, this criteria is non-deterministic as many circumstances (i.e., network load, server maintenance operations) can temporarily influence the performance of a slave and could lead to an incorrect selection of the most appropriate candidate. For example, the slave with the best hardware should be in the long run the most appropriate candidate to become the new master, but for some unanticipated reason it might actually had less transactions than other servers when the master crashed. Therefore, a more deterministic criteria based on the order in which the servers are specified is used, allowing the user to control the order in which the candidates are selected. The first server that will meet the required election criteria, consisting on simple sanity checks (server reachable and running with the required options: GTID ON and binary logging enabled), will be chosen. More specifically, the section of the new master will follow this order: first, sequentially check the list of servers specified by the --candidates option, then the servers listed in the --slaves option, finally check any discovered slave in an unordered way.