【複製】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/