About MHA
MHA (Master High Availability) currently in terms of high availability MySQL is a relatively mature solution, which consists of Japan's DeNA youshimaton employees (now at the Facebook company) to develop, is a good as the next MySQL high availability environment to switch malfunction and master-slave role to enhance the high availability software. In MySQL failover process, the MHA primary database can be done automatically in 30 seconds from 0 to the switching operation from the fault, and the process of performing failover, the MHA to ensure consistency of the data to the maximum extent to achieve high availability in the true sense.
MHA consists of two parts: MHA Manager (management node), and the Node MHA (node data) . MHA Manager can be deployed individually manage a plurality of master-slave cluster on a separate machine, it can be deployed on a slave node. MHA Node running on each server and MySQL Manager server, MHA Manager will regularly detect master node in the cluster when the master fails, it can automatically have the latest data of the slave to be the new master, and then all the other slave redirected to the new upgrade of the master. The entire failover process is completely transparent to the application level.
In the MHA automatic failover process, MHA will try to save the binary log from the primary server goes down, the greatest degree of assurance that data is not lost, but this operation is probabilistic. For example, if the primary server hardware failure or inability to access via ssh, MHA can not save the binary log, perform failover only result in the loss of the latest data. MySQL 5.5 using semi-synchronous replication, may reduce the risk of data loss. MHA can be combined with the semi-synchronous replication. If only one slave has received the latest binary log, MHA latest binary log can be applied to all other slave servers, so you can ensure data consistency across all nodes.
Currently MHA main support infrastructure a master multi-slave, to build MHA, requested a copy cluster must have at least three database servers , a primary two act as from the library from that one acts as a master, one acts as a backup master, the other one because it requires at least three servers, machines for cost considerations, Taobao also been transformed on the basis of the current Taobao TMHA already supports a master-slave. Also for those who want to quickly build can refer to: MHA quickly build our own use can actually be used from the main 1, but can not switch the master host is down, and the inability to completion binlog. After the master mysqld process crash, or you can switch successfully, as well as completion of binlog.
Official description: https: //code.google.com/p/mysql-master-ha/
work process
(1) down from the collapse of the master try to save the binary log events (binlog events);
(2) identifying the server containing the latest update of slave;
(3) difference in application logs relay (relay log) to other Slave;
(4) application binary log events saved from the master (binlog events);
(5) lift a slave as the new master server;
(6) the other connection point to the new master slave master-slave replication;
MHA tool introduced
MHA software consists of two parts, and the Node Manager Toolkit kit specifically described as follows.
Manager Kit includes the following tools:
SSH configuration status ➢ masterha_check_ssh examination of MHA
➢ masterha_check_repl check the status of MySQL replication
➢ masterha_manger start MHA
➢ masterha_check_status detect the current running state of the MHA
➢ masterha_master_monitor detect whether the master is down
➢ masterha_master_switch failover control (automatic or manual)
➢ masterha_conf_host add or remove server configuration information
Node Kit (These tools are usually triggered by MHA Manager scripts without manual operation) includes the following tools:
➢ save_binary_logs preservation and replication master binary log
➢ apply_diff_relay_logs relay event log events and identifying differences differences applicable to other slave
➢ filter_mysqlbinlog removing unnecessary ROLLBACK event (MHA no longer use this tool)
➢ purge_relay_logs Clear relay log (does not block SQL thread)
Note: In order to reduce as much as possible the main library hardware downtime caused by the loss of data corruption, so configure MySQL MHA advice configured semi-synchronous replication 5.5. About half synchronous replication principle review you own. (Not required)
Description MHA environment
for all operating systems are 64bit, the main problem behind the building from the replication environment will simply demonstrate the steps, but will not copy the relevant security detail, MySQL Replication should be noted that involves centos 7.x:
| Character | IP addresses | CPU name | server | Database Type |
| Primary Master | 192.168.200.111 | server01 | 1 | write |
| Secondary Master | 192.168.200.112 | server02 | 2 | write |
| Slave1 | 192.168.200.113 | server03 | 3 | read |
| Slave2 | 192.168.200.114 | server04 | 4 | read |
| Manager | 192.168.200.115 | server05 | - | Monitoring replication group |
Primary Master which provide external writing services, alternative Secondary Master (actual slave to provide reading services, slave1 and slave2 also provide reading services, once the Primary Master is down, the alternative will be upgraded to the new Secondary Master Primary Master, slave1 and slave2 point to the new master.