翻译自   http://code.google.com/p/mysql-master-ha/wiki/Overview

Difficulties of Master Failover

Master Failover is not as trivial as it might seem. Take the most typical MYSQL deployment case of a single master with multiple slaves.
If the master crashes, you need to pick one of the latest slaves, promote it to the new master, and let other slaves start replication from the new master.
This is actually not trivial. Even when the most current slave can be identified, it is likely that the other slaves have not yet received all their binary log events.
Those slaves will lose transactions if connected to the new master upon commencement of replication. This will cause consistency problems.
To avoid those consistency problems, the lost binlog events (which haven't yet reached all the slaves) need to be identified and applied to each slave in turn prior to initiating replication on the new (promoted) master. This operation can be very complex and difficult to perform manually. This is illustrated in my presentation at the MySQL Conference and Expo 2011 slides (especially in p.10 as below).

/*
故障转移的困难
主故障转移并不像他看起来那么简单。以最典型，一个master与多个slave，这样的MySQL部署情况来说。
如果master崩溃，你需要挑一个最新slave，提升他为新的master，并让其他的slave从这个新的master开始复制
其实，这不是那么简单的。即使当最新的slave可以被识别，它也很可能是其他的slave还没有收到所有的二进制日志事件。
这些slave将失去事务，如果连接到新的master上，开始复制，这将会引起一致性问题。
为了避免这些一致性的问题，在启动新(晋升)主复制之前，丢失的binlog事件（还没有达到所有的slave），需要确定并应用到每一个slave上
此操作可以手动执行非常复杂和困难
*/



Currently most MySQL Replication users have no choice but to perform failover manually on master crashes.
One or more hours of downtime are not uncommon to complete failover.
It is likely that not all slaves will have received the same relay log events, resulting in consistency problems later which will have to be corrected later.
Even though master crashes are infrequent, they can be very painful when they occur.

/*
目前，大多数MySQL复制用户别无选择，只能在master崩溃时进行手动故障转移
一个小时或更长时间的停机的情况并不少见，以完成故障转移。
这是可能的，并不是所有的slave将获得相同的中继日志事件，导致一致性问题以后将不得不予以纠正。
即使主崩溃是罕见的，当他们出现时则是非常痛苦的
*/




MHA aims to fully automate master failover and recovery procedures as quickly as possible, without any passive (standby) machine.
Recovery includes determining the new master, identifying differential relay log events between slaves, applying necessary events to the new master, syncing the other slaves and have them start replication from the new master.
MHA normally can to failover in 10-30 seconds of downtime (10 seconds to detect master failure, optionally 7-10 seconds to power off the master machine to avoid split brain, a few seconds or more for recovery), depending on replication delay.


/*
MHA的目的是完全自动化主节点故障转移和恢复过程尽可能快，无任何被动机（待机）。
恢复包括确定新的master，识别slave之间差异的relay log日志事件，应用必要的事件到新的master上，同步其他slave，让他们跟新的master开始复制。
MHA通常可以进行故障转移的停机时间在10-30秒（10秒检测主机故障，可选择7-10秒，关闭主机电源，以避免脑裂，几秒钟或更长时间的恢复），取决于复制延误。
*/


MHA provides both automated and manual failover commands.
The automated failover command "masterha_manager (MHA Manager)" consists of master monitoring and master failover.
masterha_manager permanently monitors the master server's availability. If MHA Manager cannot reach the master server, it automatically starts non-interactive failover procedures.
'

/*
MHA提供自动和手动故障转移命令。
自动化的故障转移命令的“masterha_manager（MHA经理）”，由master监测和master故障转移组成
masterha_manager永久监视主服务器的可用性。如果MHA经理不能达到的主服务器，它会自动启动非交互式故障转移程序。
*/



The manual failover command "masterha_master_switch" initially checks to see that master is in fact dead.
If the master is really dead, masterha_master_switch picks one of the slaves as a new master (you can choose a preferred master), and initiates recovery and failover.
Internally it does much more, but you execute only one command, without having to perform complex master recovery and failover operations on your own.


/*
手动故障转移命令的“masterha_master_switch”首先检查看实际中master是否死掉
如果master真的是死了，masterha_master_switch挑选slave中的一个，作为新的master（你可以选择一个优先权master），并启动恢复和故障转移。
在内部它执行很多东西，但是你只执行了一个命令，而无需你自己执行复杂的master的恢复和故障转移操作。
*/