In reality, the main and most important step is the execution of the switchover command with the mysqlrpladmin utility. The previous steps can be seen as a preparation for switchover. The first step simply makes sure that the server is running and that there is no mysqlfailover instance still running that could affect the correct execution of switchover. The second step sets the old master as a slave of the new master, because the switchover command can only be performed with slaves. This step will also allows the old master to catch up with the new master. If many transaction have been performed on the new master it is recommended to wait a while here to let the old master catch up before switchover, otherwise the switchover command might take too much time.
As expected, the execution of the switchover command requires
the specification of the current and new master with the
--new-master options, as
well as the list of slaves in the topology using the
--slaves option (without
need to list the new master). The replication user is
specified with the
--rpl-user option. In
this specific example, the use of the option
important, because without it the current master
(server2:3312) will not be demoted and set as a slave of the
new master (server1:3311).
The mysqlrpladmin utility will execute and display information about all required action to perform switchover. After completing the switchover process, an health report is displayed where it is possible to confirm the successful execution of the command and verify that the topology has changed as expected.
After completing these simple steps, the replication topology
is back to its initial structure (before failover) with its
old master. Therefore, mysqlfailover is
ready to be executed again to monitor the topology and enable
automatic failover. Note that in this particular situation,
the use of the
option might be required because it is likely that some
registration data from the previous failover instance
execution might have be left on the recovered master (due to
its previous crash).
The mysqlfailover utility registers its
execution on the servers in order to avoid concurrent
executions of the utility which will likely lead to errors and
inconsistent state during failover. If the utility detects
that another instance might be running, it will be started in
"fail" mode (not taking any action when it detects that the
master failed). The mysqlfailover instance
registration is cleared when the utility exits, and it is
expected that unregistration fails on crashed or not
accessible servers. The
--force option overwrite
the instance execution check allowing to surpass
unregistration failure on (crashed) old masters, allowing the
mysqlfailover utility to start in 'auto'