Brief introduction
MHA (Master High Availability) currently in terms of high availability MySQL is a relatively mature solution that youshimaton by the Japanese company DeNA (Facebook now working in the company) to develop, is a good case as a failure MySQL high availability environment and the main switch from an elevated high availability software. In MySQL failover process, the MHA can be done automatically in 30 seconds from 0 to the fault switching operation of the database, and performing the handover procedure failure, the MHA to ensure consistency of the data to the maximum extent, in order to achieve real availability of meaning.
The software consists of two parts: MHA Manager (management node) and MHA Node (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 MySQL running on each server, master node MHA Manager will regularly detect the cluster, when the master fails, it can automatically slave to the latest data of the upgrade to the new master, and then all the other slave redirected to the new the master. The entire failover process is completely transparent to the application.
In the MHA automatic failover process, MHA attempt to save down from the master binary log, without losing the greatest degree of assurance of data, but this is not always feasible. For example, if the primary server hardware failure or inability to access via ssh, MHA can not save the binary log, perform failover only lost the latest data. MySQL 5.5 using semi-synchronous replication, can greatly 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. MHA suitable for any storage engine, as long as it supports the master copy from storage engine, is not limited to support things innodb engine.
Official description: https: //code.google.com/p/mysql-master-ha/
The following figure shows how to manage multiple sets of master-slave replication by MHA Manager
MHA works can be summarized as follows:
(1 ) Save the binary event log (binlog events) down from the collapse of the master; ( 2 ) identifying the latest update comprising slave; ( 3 ) difference in application logs relay (relay log) to other Slave; ( 4 ) application binary log events saved from the master (binlog events); ( 5 ) a lift for the new Master slave; ( 6) so that other new master slave connection replication;
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
detecting a current running state of the MHA masterha_check_status
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
The relay event log events identified apply_diff_relay_logs difference and the difference is applied to the other slave
filter_mysqlbinlog removing unnecessary ROLLBACK event (MHA no longer use this tool)
purge_relay_logs Clear relay logs (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)
1. Deploy MHA
Next deployment MHA, specific build environment as follows (all operating systems are CentOS7.4 64bit):
| IP addresses |
CPU name |
Character |
software |
| 192.168.1.30 |
linzi |
manager |
mha4mysql-manager、mha4mysql-node |
| 192.168.1.25 |
KVM1 |
master |
mha4mysql-node |
| 192.168.1.26 |
KVM2 |
Slave1,Candicate master |
mha4mysql-node |
| 192.168.1.27 |
KVM3 |
Slave2 |
mha4mysql-node |
Which provide external master writing services, provide alternative Candicate master reading service (actually slave1), slave2 also provide reading services, once the master goes down, the alternative will be promoted to master a new master, slave point to the new master
perl modules (1) required for installation of all the nodes in node MHA (DBD: mysql), the installation script as follows:
First install epel source,
Centos6 installation source: RPM -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
Centos7 installation source: rpm -ivh http://www.rpmfind.net/linux/epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm
The following set CentOS6 operation:
[Warm] name=Extra Packages for Enterprise Linux 6 - $basearch baseurl = HTTP: //download.fedoraproject.org/pub/epel/6/$basearch # will remove the comment # # mirrorlist = HTTPS: //mirrors.fedoraproject.org/metalink EPEL-repo = 6 & Arch = $ basearch #? preceded by the #
yum Clean All yum list
Installation all rely on using yum
yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager --skip-broken
(2) Upload MHA related package, installation mha-node in all the nodes: