MySQL本身沒有提供replication failover的解決方案(見How can I use replication to provide redundancy or high availability?)

如何使Replication方案具有HA？

答案是MMM(MySQL Master-Master Replication Manager)

MMM對MySQL Master-Slave Replication絕對是一個很有益的補充!

引言

Master-Slave的資料庫機構解決了很多問題，特別是read/write比較高的web2.0應用：
1、寫操作全部在Master結點執行，並由Slave資料庫結點定時(預設60s)讀取Master的bin-log
2、將眾多的使用者讀請求分散到更多的資料庫節點，從而減輕了單點的壓力

這是對Replication的最基本陳述，這種模式的在系統Scale-out方案中很有引力(如有必要，資料可以先進行Sharding，再使用replication)。

它的缺點是：
1、Slave實時性的保障，對於實時性很高的場合可能需要做一些處理
2、高可用性問題，Master就是那個致命點(

SPOF:Single point of failure)

本文主要討論的是如何解決第2個缺點。

DB的設計對大規模、高負載的系統是極其重要的。高可用性(High availability)在重要的系統(critical System)是需要架構師事先考慮的。存在SPOF:Single point of failure的設計在重要系統中是危險的。


Master-Master Replication
1、使用兩個MySQL資料庫db01,db02，互為Master和Slave，即：
一邊db01作為db02的master，一旦有資料寫向db01時，db02定時從db01更新
另一邊db02也作為db01的master，一旦有資料寫向db02時，db01也定時從db02獲得更新
(這不會導致迴圈，MySQL Slave預設不會記錄Master同步過來的變化)

2、但從AppServer的角度來說，同時只有一個結點db01扮演Master，另外一個結點db02扮演Slave，不能同時兩個結點扮演Master。即AppSever總是把write操作分配某個資料庫(db01)，除非db01 failed，被切換。

3、如果扮演Slave的資料庫結點db02 Failed了：
a)此時appServer要能夠把所有的read,write分配給db01，read操作不再指向db02
b)一旦db02恢復過來後，繼續充當Slave角色，並告訴AppServer可以將read分配給它了

4、如果扮演Master的資料庫結點db01 Failed了
a)此時appServer要能夠把所有的寫操作從db01切換分配給db02，也就是切換Master由db02充當
b)db01恢復過來後，充當Slave的角色，Master由db02繼續扮演

難點：
3、4要如何自動進行？

Master-Master with n Slaves Replication


這比上一個還要複雜，即：
當一個Master Fail時，所有的Slave不再從原來失敗的那個Master(db01)獲取更新日誌，而應該“自動”切換到最新充當Master角色的資料庫db02。

MMM，a greate project!
MMM的基本資訊請參考它的網站(見後"參考資料")
MMM有3個重要的器件:
1、mmmd_mon - monitoring script which does all monitoring work and makes all decisions about roles moving and so on.
2、mmmd_agent - remote servers management agent script, which provides monitoring node with simple set of remote services to make servers management easier, more flexible abd highly portable.
3、mmm_control - simple script dedicated to management of the mmmd_mon processes by commands.

每一個MySQL伺服器器結點需要執行mmmd_agent，同時在另外的一個機器上(可以是獨立的一臺機器，也可以是和AppServer共享同一個伺服器)執行mmmd_mon。形成1 * mmmd_mon + n * mmmd_agent的部署架構。

MMM利用了虛擬IP的技術：1個網絡卡可以同時使用多個IP。
(所以使用MMM時，需要2*n+1個IP，n為mysql資料庫結點個數，包括master,slave)

當有資料庫結點fail時，mmmd_mon檢測不到mmmd_agent的心跳或者對應的MySQL伺服器的狀態，mmmd_mon將進行決定，並下指令給某個正常的資料庫結點的mmmd_agent，使得該mmmd_agent“篡位”使用(注)剛才fail的那個結點的虛擬IP，使得虛擬IP實際從指向fail的那個機器自動轉為此時的這個正常機器。
注：據Qieqie猜測是將獲得的虛擬IP設定給網絡卡，也只能這樣了，改天測試驗證一下。

repeat: MMM對MySQL Master-Slave Replication絕對是一個很有益的補充!

參考資料
Switching Masters During Failover
http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-switch.html

downpour: 討論一下基於Master-Slave資料庫模式的J2EE開發的框架選擇
http://www.javaeye.com/topic/143714

MMM http://blog.kovyrin.net/mysql-master-master-replication-manager/
Project page on Google Code: http://code.google.com/p/mysql-master-master
mmm-devel users group: http://groups.google.com/group/mmm-devel