MySQL High-availability Scenario MHA deployment and rationale

Behind the deep logic:

MHA node runs on each MySQL node, and MHA Manager periodically probes the master node in the cluster, and when master fails, it automatically promotes the slave of the latest data to master, and then points all other slave to the new master.

In the MHA automatic failover process, MHA attempts to save the master binary log to maximize the data is not lost, when this is not always feasible, for example, the primary server hardware failure or cannot be accessed through SSH, MHA can not save the binary log, This only fails over, but the latest data is lost. You can reduce the risk of data loss by combining the semi-synchronous replication that is available in MySQL 5.5.

1.MHA Setting requirements

MHA The MySQL replication environment has special requirements, such as each node to open the binary log and relay log, each from the node must explicitly enable its read-only properties, and turn off the Relay_log_purge function, and so on, here first to explain its configuration.

(GO) MySQL high-availability Scenario MHA deployment and rationale