一、来源及原理：
众所周知，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