一、来源及原理：

　　　众所周知，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

[MySQL] 高可用架构MMM简单介绍