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