一、來源及原理：
眾所周知，MySQL自身提供了AB復制（主從復制），然后可以很輕松實現master-master雙向復制，同時再為其中一個Master節點搭建一個Slave庫。
這樣就實現了MySQL-MMM架構的基礎：master1和master2之間雙向復制，同時Master1和Slave1之間是主從復制。這樣整個體系中存在兩個Master，正常情
況下只有一個master對外提供寫服務。如果對外提供服務的master意外宕機了，這是MySQL本身並不具備failover切換的能力，盡管集群中仍然有一個正常的master節點，
但應用仍不可用。mysql-mmm就是為了解決這個問題誕生的。
MySQL-MMM是Master-Master Replication Manager for MySQL（mysql主主復制管理器）的簡稱，是Google的開源項目（Perl腳本），主要用來監控mysql主主復制並做失敗轉移。
其原理是將真實數據庫節點的IP（RIP）映射為虛擬IP（VIP）集，在這個虛擬的IP集中，有一個專用於write的IP，多個用於read的IP，這個用於Write的VIP映射着
數據庫集群中的兩台master的真實IP（RIP），以此來實現Failover的切換，其他read的VIP可以用來均衡讀（balance）。
其結構圖如下：
二、優缺點：
優點：
1、自動的主主Failover切換 2、多個Slave讀的負載均衡。
缺點：
1、無法完全保證數據的一致性（在db1宕機過程中，一旦db2落后於db1,這時發生切換，db2變成了可寫狀態，數據的一致性就無法保證）
2、無論何時，只有一個數據庫可寫；db1宕機后，write VIP會指向db2，當db1恢復后，db1不會自動變成可寫主，需要手動move_role 或者db2宕機。
所以read host要包括db1，不然容易造成浪費；
3、由於是使用虛擬IP浮動技術，類似Keepalived，故RIP（真實IP）要和VIP（虛擬IP）在同一網段；如果是在不同網段也可以，需要用到虛擬路由技術。
但是絕對要在同一個IDC機房，不可跨IDC機房組建集群。
LVS-DR VIP和RIP不同網段的配置方法 ：http://blog.itpub.net/124805/viewspace-1047686/；http://zh.linuxvirtualserver.org/node/28
4、monitor單點問題，或許可以用keepalived來解決。
三、MySQL-MMM Monitor：
1、6種狀態
1）ONLINE 正常運行狀態
2）ADMIN_OFFLINE 人工設置為離線狀態
3）HARD_OFFLINE 離線狀態(ping失敗/mysql連接失敗)
4）AWAITING_RECOVERY 主機將恢復在線
5）REPLICATION_DELAY 復制延時大(rep_backlog檢測失敗)
6）REPLICATION_FAIL 復制線程沒有運行(rep_threads檢測失敗)，復制中斷(sql_thread,io_thread)會導致replication_fail狀態
只要主機處在ONLINE才能獲得角色。當從ONLINE狀態切換到其他狀態時，角色將移除。
當主機處在REPLICATION_DELAY或REPLICATION_FAIL狀態，一旦恢復，將切換到ONLINE狀態。除非抖動不穩定。
主機在HARD_OFFLINE狀態，如果所有的問題都解決了，那么將會切換到AWAITING_RECOVERY狀態。如果它故障時間小於60s，並且它沒有重啟或者auto_set_online>0,
那么將會被自動切換到ONLINE狀態，除非抖動不穩定。
活動的主服務器復制延時或復制失敗將不被視為一個問題。因此活動的主服務器狀態不會被置於REPLICATION_DELAY或REPLICATION_FAIL。
在節點被切換到ONLINE狀態的60s內，如果復制延時或復制失敗將會被忽略(默認時間為master-connect-retry值)。
如果rep_backlog和rep_threads都檢測失敗，將會切換到REPLICATION_FAIL狀態。
2、mysql-mmm的主要功能通過以下三個腳本來實現：
mmm_mond：監控進程，監控所有服務器，決定節點角色。
mmm_agentd：代理進程，運行在每台MySQL服務器上，為監控節點聽簡單的遠程服務。
mmm_control：為mmm_mond 提供管理命令
3、角色
exclusive角色：互斥角色只有一個ip，並且同一時間只能分配給一個主機。可以指定一個首選主機（preferred 存疑？？），如果這個主機是ONLINE狀態
，那么角色將被賦予到這個主機。注意：不能移動被分配到首選主機的角色，因為他們將立刻再次被移動回到它。
balanced角色：負載均衡角色可以有多個ip。沒有一個主機可以比其他主機多出兩個角色。
4、檢測
mmm_mond對每個主機檢測4項決定是否OK
1）ping 主機是否存活
2）mysql mysqld進程是否存活
3）rep_threads 復制線程是否運行
4）rep_backlog 延時少，復制積壓的日志很少
抖動：
mmm_mond 支持抖動檢測。如果一個主機頻繁從ONLINE切換到HARD_OFFLINE或者REPLICATION_FAIL或者REPLICATION_DELAY狀態，每次切換到ONLINE狀態(auto_set_online或者
down的時間小於60s)，將會導致角色的切換非常頻繁。為了避免這種情況mmm_mond內建了flap檢測，可以通過配置文件配置。如果一個主機在flap_duration時間內宕掉了
flap_count次，就認為主機處理flap狀態，就不會自動被設置為ONLINE狀態，將一直處於AWAITING_RECOVERY狀態除非手動設置online(mmm_control set online host)。
如果auto_set_online>0,處於flapping的主機在flap_duration時間后將自動設置為ONLINE狀態
5、模式
active mode：Monitor將會自動的把角色從失敗的主機上移除，並切換到其他主機上。
manual mode：Moniter會自動把負載均衡的角色分配給對應主機，但是不會自動的把角色從失敗的主機上移除。可以通過move_role來手工移除。
wait mode：類似manual模式，但是當兩個master都是online狀態或者超過了wait_for_other_master的時間，將被切換為ACTIVE模式。
passive mode：在此模式下，monitor不會改變角色，不更新狀態文件和發送任何信息給mmm agents。在此模式下可以使用set_ip來改變roles，但是這些改變在monitor切換到
ACTIVE或者MANUAL模式(set_active or set_manual)前都不會生效。在啟動時檢測到角色發生沖突將會進入被動模式。
四、MySQL-MMM control：
通過mmm_control 命令來控制monitor守護進程，如果有多個集群，則需指定想要控制的集群名稱。
ping 檢測monitor是否存活
show 查看當前集群服務狀況
checks [host|all] 查看指定節點的狀態
set_online host 把節點的狀態從awaiting_recovery或者admin_offline恢復到online
set_offline host 為了維護一個節點，手動的將其設置為admin_offline狀態，這個節點上的所有角色都會被移除，並且停止mysql復制
mode 查看當前模式
set_active 切換monitor到active模式
set_manual 切換monitor到manual模式
set_passive 切換monitor到passive模式
move_role role host 在集群節點間切換exclusive角色。在passive模式下無效。
move_role --force role host 可以將active_master_role切換到處在REPLICATION_FAIL或REPLICATION_DELAY狀態的主機上。在passive模式下無效。
set_ip ip host 可以在passive模式下，維護角色。當monitor切換到ACTIVE或MANUAL模式下后才生效。
五、MySQL-MMM 具體搭建步驟：
官方文檔看這里：http://mysql-mmm.org/mmm2:guide
自己搭建教程看這里：暫無
六、報錯及其他：
1、linux shell 下用ip add 看虛擬ip綁定情況
2、agent端通過一系列perl腳本完成一些操作(/usr/libexec/mysql-mmm/agent/)，比如check_ip,configuer_ip