【复制】mha-1

A primary objective of MHA is automating master failover and slave promotion within short (usually 10-30 seconds) downtime, without suffering from replication consistency problems, without spending money for lots of new servers, without performance penalty, without complexity (easy-to-install), and without changing existing deployments.

/*
mha的一个主要目标是"主节点故障转移"和"slave提升"在短期的停机时间(通常为10-30秒)内，没有一致性的问题，不用为新机器花钱，没有性能损失，便于安装，不用改变现有架构
*/

MHA also provides a way for scheduled online master switch: changing currently running master to a new master safely, within a few seconds (0.5-2 seconds) of downtime (blocking writes only).

/*
mha同样也提供了一些master在线切换的任务调度，安全的变更当前的 运行的master 成为一个新的 mster，在几秒钟内的停机时间(0.5-2s，并且只block write)
*/


MHA provides the following functionality, and can be useful in many deployments where requirements such as high availability, data integrity, almost non-stop master maintenance are desired.

/*
MHA提供以下功能，可以用在许多部署，如高可用性，数据完整性，几乎在不停机的master上也是可行的
*/

1.Automated master monitoring and failover
(1) MHA has a functionality to monitor MySQL master in an existing replication environment, detecting master failure, and doing master failover automatically.
(2) Even though some of slaves have not received the latest relay log events, MHA automatically identifies differential relay log events from the latest slave, and applies differential events to other slaves.So all slaves can be consistent.
(3) MHA normally can do failover in seconds (9-12 seconds to detect master failure, optionally 7-10 seconds to power off the master machine to avoid split brain, a few seconds for applying differential relay logs to the new master, so total downtime is normally 10-30 seconds).
(4) In addition, you can define a specific slave as a candidate master (setting priorities) in a configuration file. Since MHA fixes consistencies between slaves, you can promote any slave to a new master and consistency problems (which might cause sudden replication failure) will not happen.

/*
1.自动 master 监测和故障转移
(1) mha有一个功能，是监控当前复制环境的 master，检测 master 故障，做的 master自动故障切换。
(2) 即使有些slave还没有收到最新的中继日志事件，MHA自动识别不同的relay log event从最新的slave上，然后把这些差异应用到不同的slave上，所以所有的slave都是一致性的
(3) MHA通常可以做failover秒(9-12秒检测主机故障，通常7-10秒，关闭主机电源，以避免脑裂，几秒钟的时间应用差异的relay log  
   event事件到新的主，所以总的停机时间一般为(10-30秒)。
(4) 此外，你也可以设置一个备选master(设置优先级)在配置文件中。因为 mha 修复各slave之间的一致性，
   所有你也可以提升任何的slave成为一个新的master，而不用担心一致性问题
*/

2.Interactive (manual) Master Failover
(1) You can also use MHA for just failover, not for monitoring master. You can use MHA for master failover interactively.

/*
2.交互式的(人工) master 故障切换
(1) 你可以仅仅使用 mha 的故障转移，而不监控master。你也可以交互式的使用mha的master 故障转移
*/

3.Non-interactive master failover
(1) Non-interactive master failover (not monitoring master, but doing failover automatically) is also supported.
(2) This feature is useful especially when you have already used a software that monitors MySQL master.
(3) For example, you can use Pacemaker(Heartbeat) for detecting master failure and virtual ip address takeover,
   and use MHA for master failover and slave promotion.

/*
3.非交互式 master故障转移
(1) 非交互式 master故障转移也是支持的(不监控master，但是执行自动故障转移)
(2) 此功能非常有用，尤其是当你已经使用一个软件，监控MySQL主
(3) 例如HA，虚拟ip切换等。并使用mha做故障转移和slave提升
*/

4.Online switching master to a different host
(1) In many cases, it is necessary to migrate an existing master to a different machine (i.e. the current master has H/W problems on RAID controller or RAM, you want to replace with faster machine, etc).
(2) This is not a master crash, but scheduled master maintenance is needed to do that. Scheduled master maintenance causes downtime (at least you can not write master) so should be done as quickly as possible.
(3) On the other hand, you should block/kill current running sessions very carefully because consistency problems between different masters might happen (i.e "updating master1, updating master 2, committing master1, getting error on committing master 2" will result in data inconsistency).
(4) Both fast master switch and graceful blocking writes are required. MHA provides a way to do that. You can switch master gracefully within 0.5-2 seconds of writer block.
(5) In many cases 0.5-2 seconds of writer downtime is acceptable and you can switch master even without allocating scheduled maintenance window. This means you can take actions such as upgrading to higher versions, faster machine, etc much more easily.

/*
4.在线切换master到不同的主机上
(1) 在许多情况下，迁移当前在线的master到其他机器上是必要的(例如：raid等一些内置问题)
(2) 这不是一个master崩溃，但预定的维修任务是需要做的。预定维修任务会导致停机时间（至少可以不写主），所以必须尽快完成。
(3) 另一方面，你应该阻止/杀死当前正在运行的会话非常小心，因为不同的主人之间可能发生的一致性问题
(4) master快速切换和优雅的阻塞写操作这2个操作都是必需。 MHA提供了一个方法来做到这这2个操作。您可以优雅的切换master在阻塞write操作的0.5-2内
(5) 在许多情况下，0.5-2秒不能写是可以接受的，你可以切换master即使没有分配计划这2个操作都维护任务。这意味着你可以采取升级到更高版本，更快的机器的操作。
*/


摘自：http://code.google.com/p/mysql-master-ha/