//mysql-mmm有关mmm_control参数测试
a. mmm_mond
监控进程,负责所有的监控工作,决定和处理所有节点角色活动。
b. mmm_agent
运行在每个Mysql服务器上的代理进程,完成监控的探针工作和执行简单的远端服务设置。
c. mmm_control
一个简单的脚本,提供管理mmm_mond进程的命令。
运行mmm_control show时monitor监控的mysql服务可以有如下几种状态:
online 主机正在运行,没有任何问题。
admin_offline 手动被设置成离线状态。
hard_offline 主机不在线(ping检测或者是mysql检测失败)。
awating_recovery 主机即将恢复在线。
replication_delay 复制延迟很大,积压了很多未完成的日志(rep_backlog检测失败)。
replication_fall 复制线程没有运行(rep_threads检测失败)。
当mmm_mon.conf文件的auto_set_online 10参数设置小于60时db1、db2mysql服务停止启动切换时,不会出现上述AWAITING_RECOVERY状态,只要mysql服务启动即会自动切换到online状态,当配置参数等于或者大于60时,即会出现如下状态,
当用mmm_control set_onlinedb1即可修改db1为在线online状态。
总结:只有当主机在线的时候才能获得角色(reader or writer),当一个主机从online转换到其它状态,它所获得的角色都会从它身上移除。
一个主机在replication_delay或者是replication_fall状态时,如果所有的问题都解决了,就会被再次切换到online状态,除非它的状态在抖动,不稳定。参见flapping(抖动)。
一个主机在hard_offline状态,如果所有的问题都解决了,那么它会转换到awaiting_recovery状态,如果它的故障时间小于60s,并且它没有重启或者auto_set_online>0,那么它将会被自动切换到online状态,除非它的状态在抖动,不稳定。参见flappping(抖动)。
如过活动的master出现积压了很多未完成的复制工作或者复制失败将不被视为一个问题,所以活动的master不会被置于replication_delay或者REPLICATION_FAIL状态。
在节点被转换到ONLINE状态60s内,如果出现复制失败或者出现积压了很多未完成的复制工作将会被忽略(这个时间通过master-connect-retry来控制)。
如果rep_backlog和rep_threads都检测失败,将会切换到REPLICATION_FAIL状态。
在mmm_common.conf
exclusive roles
互斥角色只有一个ip,并且同一时间只能分配给一个主机,你可以指定一个优先(preferred)主机,如果这个主机是ONLINE状态,那么角色就会被切换到这个主机。
balanced roles
负载均衡角色可以有多个IP,这些IP被均衡的分配给多个主机,所以没有一个主机可以比其他主机多出两个角色。
(备忘录:可以通过给可写的active_master_role设置mode=slave把角色切换给其他master)。
mmm_controlcheck
mmm_mond会对每个主机执行4项检查,并决定检查是否成功:
ping -- ----主机可以ping通。
mysql -- ----mysql server在线
rep_threads -- ----复制线程在运行
rep_backlog -- ----复制积压的日志很少
Monitor将会自动的把角色从失败的主机上移除,并切换到其他主机上。
Moniter会自动把负载均衡的角色分配给对应主机,但是不会自动的把角色从失败的主机上移除。你可以通过move_role来手工移除。
类似manual模式,但是当两个master都是online状态或者超过了wait_for_other_master的时间,将被改变为ACTIVE模式。
在被动模式下,monitor不改变roles,也不更新状态文件和发送任何信息给agents。在被动模式下你可以使用set_ip来改变roles,但是这些改变在monitor切换到ACTIVE或者MANUAL模式(set_active or set_manual)前都不会生效,在启动的roles发生冲突将会进入被动模式。你可以分析问题,修复reole信息,然后切换到ACTIVE或者MANUAL模式,也可以手动进去被动模式,使用 set_passive。