MySQL MHA Failover Process and Master‑Slave Configuration Steps

When a MySQL master node fails, MHA (Master High Availability) first tries to save the master’s binary logs, then automatically identifies which slave holds the newest relay log, transfers the necessary diff logs to other slaves, applies the saved binary log events, and finally promotes the selected slave to become the new master, ensuring data consistency across the cluster.

The overall workflow includes: attempting to save the binary log from the failed master, locating the slave with the latest relay log, applying that relay log to other instances, applying the saved binary log events, promoting a slave to master, and synchronizing the remaining slaves to the new master.

Configuration steps:

1. Create a replication user on each server: mysql> CREATE USER 'repl'@'192.168.236.%' IDENTIFIED WITH mysql_native_password BY '123456'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.236.%'; mysql> FLUSH PRIVILEGES; mysql> SHOW MASTER STATUS;

2. On each slave (e.g., slave1 and slave2 ), configure the master connection: mysql> CHANGE MASTER TO MASTER_HOST='192.168.236.179', MASTER_USER='repl', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=868; mysql> START SLAVE; Verify the slave status with: mysql> SHOW SLAVE STATUS\G;

After executing these commands, the master‑slave replication topology is successfully established, allowing MHA to perform automatic failover with minimal data loss.