Shulou(Shulou.com)06/01 Report--

Introduction to MHA

MHA is a relatively mature MySQL high availability scheme developed by Japanese youshimaton (formerly working in DeNA and now working in FaceBook). MHA can fail over within 30 seconds and ensure data consistency as much as possible during the failover. At present, Taobao is also developing a similar product TMHA, which now supports one master and one slave.

MHA architecture

MHA consists of MHA Manager and MHA Node. As shown below:

MHA Manager

Run some tools, such as masterha_manager tools for automatic monitoring of MySQL Master and master failover, other tools for manual master failover, online mater transfer, connection checking, and so on. A single Manager can manage multiple master-slave clusters.

MHA Node

Deployed on all servers running MySQL, whether master or slave. There are three main functions.

Ⅰ, save binary log

If the failed master is accessible, the binary log of master will be copied.

II, Application differential Relay Log

Generate a differential relay log from the slave that has the latest data, and then apply the differential log.

III, clear relay log

Delete the relay log without stopping the SQL thread

How MHA works

When the master fails, the nearest slave is selected as the latestslave by comparing the position where the slave is read by the masterbinlog O thread. Other slave generates differential relay logs by comparing with latest slave. Apply the binlog saved from master on latest slave, while promoting latest slave to master. Finally, apply the corresponding differential relay log to other slave and start replication from the new master.

In the process of Master failover implemented by MHA, MHA Node will try to access the failed master (through SSH). If it can be accessed (not due to hardware failure, such as corrupted InnoDB data files, etc.), binaries will be saved to ensure that the data is not lost as much as possible. Using MHA in conjunction with semi-synchronous replication greatly reduces the risk of data loss.

Current high availability scenarios

Heartbeat+DRBD

Cost: need to add additional passive master server (does not handle application traffic)

Performance: in order for the DRBD replication environment to be highly available, innodb-flush-log-at-trx-commit and sync-binlog must be set to 1, which can lead to write performance degradation.

Consistency: the necessary binlog time on master may be lost so that slave cannot replicate, resulting in data consistency issues.

MySQL Cluster

MySQL Cluster really achieves high availability, but uses the NDB storage engine, and the SQL node has a single point of failure.

Semi-synchronous replication (5.5 +)

Semi-synchronous replication greatly reduces the problem that "binlog events only exists on failed master".

When submitting, make sure that at least one slave (not all) receives the binlog, so some slave may not receive the binlog.

Global transaction ID

Adding a global transaction ID (global transaction id) to the binary file requires a change to the binlog format, which is not supported in version 5.1.

In application, there are many methods for linear global transaction ID, but it still can not avoid the problems of complexity, performance, data loss or consistency.

PXC

PXC implements high availability of services and concurrent replication when data is synchronized. But only the InnoDB engine is supported, and all tables must have primary keys. There are many problems such as lock conflicts, deadlock problems and so on.

Advantages of MHA

1. Fast failover

In a master-slave replication cluster, MHA can usually fail over in seconds as long as the slave library has no delay in replication. If a master failure is detected within 9-10 seconds, you can choose to shut down the master in 7-10 seconds to avoid brain cracking, and within a few seconds, the differential Relay Log (relay log) is applied to the new master, so the total downtime is usually 10-30 seconds. After restoring the new master, MHA restores the rest of the slave in parallel. Even if there are tens of thousands of slave, it will not affect the recovery time of master.

DeNA uses MHA in more than 150 MySQL (mainly 5.0 server 5.1) master-slave environments. When mater fails, MHA completes the failover within 4 seconds. In a traditional active / passive clustering solution, it is impossible to complete a failover in 4 seconds.

2. Master failure will not cause data inconsistency.

When the current master fails, the MHA automatically identifies the difference in the relay log (relay log) between the slave and applies it to all slave. In this way, all salve can be kept synchronized, as long as all slave are alive. Used with Semi-Synchronous Replication, there is (almost) no data loss guaranteed.

3. There is no need to modify the current MySQL settings

One of the important principles of MHA's design is to be as simple and easy to use as possible. MHA works in a master-slave replication environment of traditional MySQL version 5.0 and later. Compared with other highly available solutions, MHA does not need to change the deployment environment of MySQL. MHA is suitable for asynchronous and semi-synchronous master-slave replication.

Start / stop / upgrade / downgrade / install / uninstall MHA there is no need to change (package expansion start / stop) MySQL replication. When you need to upgrade MHA to a new version, you don't need to stop MySQL, just replace it with the new version of MHA, and then restart MHA Manager.

MHA runs on the native version of MySQL 5.0. Some other MySQL high availability solutions require specific versions (such as MySQL clusters, MySQL with global transaction ID, etc.), but do not migrate applications just for the high availability of master. In most cases, older MySQL applications have been deployed, and you don't want to spend too much time migrating to different storage engines or newer cutting-edge releases just to achieve high availability of Master. MHA works on MySQL, which includes the native version of 5.0 Charpy 5.1 and 5.5, so there is no need for migration.

4. There is no need to add a large number of servers

MHA consists of MHA Manager and MHA Node. MHA Node runs on a MySQL server that requires failover / recovery, so no additional servers are required. MHA Manager runs on specific servers, so you need to add one (two to achieve high availability), but MHA Manager can monitor a large number (or even hundreds) of individual master, so there is no need to add a large number of servers. Even running MHA Manager on a slave is OK. To sum up, there is no need to add a lot of services to implement MHA.

5. No performance degradation

MHA is suitable for asynchronous or semi-synchronous MySQL replication. When monitoring master, MHA simply sends a ping packet every few seconds (the default is 3 seconds) and does not send a re-query. You can get performance as fast as native MySQL replication.

6. Suitable for any storage engine

MHA can run on storage engines that run as long as MySQL replication runs, and is not limited to InnoDB, even in traditional MyISAM engine environments that are not easy to migrate. MHA can be used.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.