MHA有如下特性：
1.主服務器的自動監控和故障轉移
MHA監控複製架構的主服務器，一旦檢測到主服務器故障，就會自動進行故障轉移。即使有些從服務器沒有收到最新的relay log，MHA自動從最新的從服務器上識別差異的relay log並把這些日誌應用到其他從服務器上，因此所有的從服務器保持一致性了。MHA通常在幾秒內完成故障轉移，9-12秒可以檢測出主服務器故障，7-10秒內關閉故障的主服務器以避免腦裂，幾秒中內應用差異的relay log到新的主服務器上，整個過程可以在10-30s內完成。還可以設置優先級指定其中的一臺slave作爲master的候選人。由於MHA在slaves之間修復一致性，因此可以將任何slave變成新的master，而不會發生一致性的問題，從而導致複製失敗。
2.交互式主服務器故障轉移
可以只使用MHA的故障轉移，而不用於監控主服務器，當主服務器故障時，人工調用MHA來進行故障故障。
3.非交互式的主故障轉移
不監控主服務器，但自動實現故障轉移。這種特徵適用於已經使用其他軟件來監控主服務器狀態，比如heartbeat來檢測主服務器故障和虛擬IP地址接管，可以使用MHA來實現故障轉移和slave服務器晉級爲master服務器。
4.在線切換主服務器
在許多情況下，需要將現有的主服務器遷移到另外一臺服務器上。比如主服務器硬件故障，RAID控制卡需要重建，將主服務器移到性能更好的服務器上等等。維護主服務器引起性能下降，導致停機時間至少無法寫入數據。另外，阻塞或殺掉當前運行的會話會導致主主之間數據不一致的問題發生。MHA提供快速切換和優雅的阻塞寫入，這個切換過程只需要0.5-2s的時間，這段時間內數據是無法寫入的。在很多情況下，0.5-2s的阻塞寫入是可以接受的。因此切換主服務器不需要計劃分配維護時間窗口(呵呵，不需要你在夜黑風高時通宵達旦完成切換主服務器的任務)。
注：MHA可以應用於任何複製結構
二． MHA所需條件
1.SSH公鑰驗證
MHA管理節點通過ssh連接mysql服務器，MHA節點通過scp發送最新的relay log到其他slaves服務器上。爲了使這些過程自動化，使用SSH公鑰驗證密碼。
2.操作系統
MHA目前只支持Linux系統
3.單臺可寫主服務器和多臺從服務器或只讀主服務器
當主服務器當掉時，MHA修復從服務器之間數據一致性。MHA試圖從當掉的主服務器上保存尚未發送的二進制日誌文件並應用於所有從服務器。如果只有一個從服務器，就不需在意從服務器之間一致性問題。即使只有一個從服務器，MHA也會從當掉的主服務器上保存尚未發送的二進制日誌事件只要能通過ssh訪問到主服務器。使用半同步複製可以解決當主服務器當掉後，無法ssh到主服務器上保存尚未發送的二進制日誌事件。
從MHA Manager0.52版本開始，支持多主複製結構。只允許其中一臺主服務器可寫，其他主服務器必須設置read-only=1。默認情況下，被管理服務器應該是兩層複製結構。
4.在三層或三層以上覆制情況下
默認情況下，MHA不支持三層或三層以上的複製結構。如master1—master2—-slave3。MHA故障轉移和恢復是直接從從服務器中選擇一臺作爲當前的主主服務器。MHA可以管理master1和master2，當master1當掉後，將master2作爲主，MHA不會監控和恢復slave3因爲slave3是從不同的主服務器上(master2)複製的。爲了使MHA工作在這種架構下，需要做如下設置：
只在MHA配置文件中配置master1和master2
在MHA配置文件中所有主機上設置multi_tier_slave=1
在這種情況下，MHA只管理主主服務器和二層的從服務器，在故障轉移過程中，三層從服務器仍然可以正常工作的。
5.mysql版本5.0或更高
MHA支持mysql5.0或以上版本。因爲從mysql5.0版本起二進制日誌格式(binlog v4格式)改變了。當MHA解析二進制日誌來確定目標中繼日誌位置，是使用v4格式的。MySQL版本不得低於5.0.60。
6.mysqlbinlog版本3.3或更高
MHA在目標從服務器上應用二進制事件使用mysqlbinlog。如果主服務器使用基於行格式複製，基於行格式的事件寫入到二進制文件中，這種二進制日誌格式的文件只能被MySQL5.1或更高版本的mysqlbinlog解析。MySQL5.0.60以下版本中的mysqlbinlog不支持基於行格式的。
7.候選主服務器log-bin必須開啓
如果當前的從服務器沒有開啓log-bin，那麼將不可能成爲主服務器。MHA管理節點會檢測是否有配置log-bin。如果當前所有從服務器都沒有設置log-bin，那麼MHA不進行故障轉移。
8.所有服務器上的二進制日誌和中繼日誌過濾規則必須相同
binlog-do-db和replicate-ignore-db設置必須相同。MHA在啓動時候會檢測過濾規則，如果過濾規則不同，MHA不啓動監控和故障轉移。
9.候選主服務器上的複製用戶必須存在
當故障轉移後，所有從服務器上將執行change master to命令。
10.保留中繼日誌和定期清理
默認情況下，從服務器上的中繼日誌在SQL線程執行完後會被自動刪除的。但是這些中繼日誌在恢復其他從服務器時候可能會被用到，因此需要禁用中繼日誌的自動清除和定期清除舊的中繼日誌。定期清除中繼日誌需要考慮到複製延時的問題。在ext3文件系統下，刪除大的文件需要一定的時間，會導致嚴重的複製延時。爲了避免複製延時，暫時爲中繼日誌創建硬鏈接。
MHA節點包含pure_relay_logs命令工具，它可以爲中繼日誌創建硬鏈接，執行SET GLOBAL relay_log_purge=1，等待幾秒中以便SQL線程切換到新的中繼日誌，再執行SET GLOBAL relay_log_purge=0。
pure_relay_logs參數如下所示：
–user mysql用戶名
–password mysql密碼
–host mysql服務器地址
–port 端口號
–workdir 創建和刪除中繼日誌硬鏈接目錄。成功執行腳本後，硬鏈接的中繼日誌文件將被刪除。默認目錄是/var/tmp。
–disable_relay_log_purge 如果relay_log_purge=1，purge_relay_logs腳本將退出不做任何事情。設置–disable_relay_log_purge參數，purge_relay_logs腳本不會退去，且自動設置relay_log_purge=0。
定期執行purge_relay_logs腳本：
Purge_relay_logs腳本刪除中繼日誌不會阻塞SQL線程。因此在每臺從服務器上設置計劃任務定期清除中繼日誌。
00 00 * * * /usr/bin/purge_relay_logs –user=root –password=passwd –disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.log 2>&1
最好在每臺從服務器上不同時間點執行計劃任務。
11. LOAD DATA INFILE不要使用基於語句型的二進制日誌
如果使用非事務性存儲引擎，在執行完LOAD DATA INFILE基於語句型二進制日誌時，主服務器當掉，MHA可能不會產生差異的中繼日誌事件。使用LOAD DATA INFILE基於語句型二進制日誌有一些已知問題，在mysql5.1版本中不建議使用，同時還會引起嚴重的複製延時，因此沒有理由使用它。
網上一篇關於MHA的好文章：