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 --master and --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 --demote-master is 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 --force 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' mode.

User Comments
Sign Up Login You must be logged in to post a comment.