MySQL MHA Introduction and its advantages

MHA is the most efficient use of MySQL database Enterprise choice, it is simple and powerful, the implementation of the MySQL replication architecture based automatic master-slave failover, this article mainly uses the original text to describe the main features of the MHA and its advantages, as far as possible through the original to understand thoroughly, For everyone's reference.

First, the main characteristics of MHA

MHA performs automating master failover and slave promotion with minimal downtime, usually within 10-30 seconds. MHA prevents replication consistency problems and saves on expenses of have to acquire additional servers. All the with zero performance degradation, no complexity (easy-to-install) and requiring no change to existing deployment S.

MHA also provides scheduled online master switching, safely changing the currently running master to a new master, within Mere seconds (0.5-2 seconds) of downtime (blocking writes only).

MHA provides the following functionality, and can be useful in many deployments in which high availability, data integrity and near Non-stop Master maintenance is required.

Automated master monitoring and failover(Automatic monitoringMasterand fail-over)

MHA can monitor MySQL masters in an existing replication environment, performing automatic master failover upon detection of master failure. MHA guarantees the consistency of all the slaves by identifying differential relay log events from the most current slave and applying them to all of the other slaves, including those slaves which still haven ' t received the latest relay log events . MHA can normally perform failover in a matter of seconds:9-12 seconds to detect master failure, optionally 7-10 seconds to power off the master machine to avoid split brain, a nd a few seconds to apply differential relay logs to the new master. Total downtime is normally 10-30 seconds. A specific slave can is designated as a candidate master (setting priorities) in a configuration file. Since MHA maintains consistency between slaves, any slave can is promoted to become the new master. Consistency problems, which would ordinarily cause sudden replication failure, would not occur.

Interactive (manually initiated) Master Failover (Interactive mode, manual triggerMasterFail over)

MHA can configured for manually initiated (non-automatic), interactive failover, without monitoring the master.

non-interactive Master Failover (Non-interactive modeMasterFail over)

Non-interactive, automatic master failover without monitoring the master is also supported. This feature was especially useful when MySQL master software monitoring was already in use. For example, you can use Pacemaker (Heartbeat) for detecting master failure and virtual IP address takeover, while Using MHA for master failover and slave promotion.

Online switching master to a different host (Online switchingMasterto the different machine)

it was often necessary to migrate an existing master to a different machine, as if the current master H As h/w RAID controller or RAM problems, or when you want to replace it with a faster machine, etc. this is isn't a master crash, but scheduled master maintenance is required. Scheduled master maintenance should is done as quickly as possible, since it entails partial downtime (master writes is D isabled). On the other hand, should block/kill current running sessions very carefully because consistency problems between diff Erent masters may occur (i.e "updating master1, updating Master 2, committing Master1, getting error on committing master 2 "would result in data inconsistency). Both Fast master switch and graceful blocking writes are required.

MHA provides graceful master switching within 0.5-2 seconds of writer blockage. 0.5-2 seconds of writer downtime is often acceptable, so can switch masters even without allocating a scheduled mainte Nance window. Actions such as upgrading to higher versions, faster machine, etc. become much easier.

Second, the advantages of MHA

Master failover and slave promotion can be done very quickly

MHA normally can do failover in seconds (9-12 seconds to detect master failure, optionally 7-10 seconds to power off the M Aster machine to avoid split brain, a few seconds for applying differential relay logs to the new master, so total Downtim E is normally 10-30 seconds), as long as slaves does not delay replication seriously. After recovering the new master, MHA recovers the rest slaves in parallel. Even though you has tens of slaves, it does not affect master recovery time, and you can recover slaves very quickly.

DeNA uses MHA on 150+ {master, slaves} environments. When one of the master crashed, MHA completed failover in 4 seconds. Doing failover in 4 seconds are never possible with traditional active/passive clustering solution.

Master crash does not result in data inconsistency

When the current master crashes, MHA automatically identifies differential relay logs events between slaves, and applies To Each slave. So finally all slaves can is in sync, as long as all slave servers is alive. By using the together with Semi-synchronous Replication, (almost) no data loss can also is guaranteed.

No need to modify-MySQL settings (MHA works with regular MySQL (5.0 or later))

one of the most important design principles of MHA are to do MHA easy to use as long as Possible. MHA works with existing traditional MySQL 5.0+ master-slaves replication environments. Though Many other HA solutions require-to-change MySQL deployment settings, MHA does isn't force such tasks for DBAs. MHA works with the most common Two-tier single master and multiple slaves environments. M HA works with both asynchronous and semi-synchronous MySQL replication. starting/stopping/upgrading/downgrading/installing/uninstalling MHA can be done without changing (including starting/stopping) MySQL replication. When you need to upgrade MHA to newer versions, you don ' t need to stop MySQL. Just Replace with newer MHA versions and restart MHA Manager is fine.

MHA works with normal MySQL versions starting from MySQL 5.0. Some HA solutions require special MySQL versions (i.e. MySQL Cluster, MySQL with Global Transaction ID, etc) Not a like to migrate applications just for master HA. In many cases people has already deployed many legacy MySQL applications and they don ' t want to spend too much time to mi Grate to different storage engines or newer bleeding edge distributions just for master HA. MHA works with the normal MySQL versions including 5.0/5.1/5.5 so you don ' t need to migrate.

No need to increase lots of servers

MHA consists of MHA Manager and MHA Node. MHA Node runs on the MySQL server is failover/recovery happens so it doesn ' t require additional server. MHA Manager normally runs on a dedicated server so you need to add one (or both for HA) server (s), but MHA Manager can Monitor lots of (even 100+) Masters from single server, so the total number of servers are not increased so much. Note that it was even possible to run MHA Manager on one of the slave servers. in this case total number of servers are not increased at all.

No Performance Penalty

MHA works with regular asynchronous or semi-synchronous MySQL replication. When monitoring master server, MHA just sends ping packets to master every N seconds (default 3) and it does not send Heav Y queries. You can expect as fast performance as regular MySQL replication.

Works with any storage engine

MHA works with any storage engines as long as MySQL replication works, not limited to InnoDB (Crash-safe, transactional St Orage engine). Even though you use legacy MyISAM environments that is not easy to migrate and you can use MHA.

MySQL MHA Introduction and its advantages