[root@mmm-monitor ~]# mmm_control show master-db1(192.168.1.11) master/ONLINE. Roles: reader(192.168.1.252) master-db2(192.168.1.12) master/ONLINE. Roles: reader(192.168.1.254), writer(192.168.1.250) slave-db1(192.168.1.13) slave/ONLINE. Roles: reader(192.168.1.251) slave-db2(192.168.1.14) slave/ONLINE. Roles: reader(192.168.1.253)
7.再次slave-db1和slave-db2主从状态
mysql> show slave status\G #slave-db1 *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.12 Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 636231 Relay_Log_File: relay-log.000002 Relay_Log_Pos: 283 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes
mysql> show slave status\G #slave-db2 *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.12 Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 636231 Relay_Log_File: relay-log.000002 Relay_Log_Pos: 283 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes
可以看到主库启动不会接管主，直到现有的主再次宕机。
mysql-mmm故障处理机制中总结：1.对外提供读写的虚拟IP是由monitor程序控制。如果monitor没有启动那么db服务器不会被分配虚拟ip,但是如果已经分配好了虚拟ip，当monitor程序关闭了原先分配的虚拟ip不会立即关闭外部程序还可以连接访问（只要不重启网络），这样的好处就是对于monitor的可靠性要求就会低一些，但是如果这个时候其中的某一个db服务器故障了就无法处理切换，也就是原先的虚拟ip还是维持不变，挂掉的那台DB的虚拟ip会变的不可访问。 2.agent程序受monitor程序的控制处理write切换，从库切换等操作。如果monitor进程关闭了那么agent进程就起不到什么作用，它本身不能处理故障。 3.monitor程序负责监控db服务器的状态，包括Mysql数据库、服务器是否运行、复制线程是否正常、主从延时等；它还用于控制agent程序处理故障。 4.monitor会每隔几秒钟监控db服务器的状态，如果db服务器已经从故障变成了正常，那么monitor会自动在60s之后将其设置为online状态(默认是60s可以设为其它的值)，有监控端的配置文件参数“auto_set_online”决定，群集服务器的状态有三种分别是：HARD_OFFLINE→AWAITING_RECOVERY→online 5.默认monitor会控制mmm_agent会将writer db服务器read_only修改为OFF，其它的db服务器read_only修改为ON,所以为了严谨可以在所有的服务器的my.cnf文件中加入read_only=1由monitor控制来控制writer和read,root用户和复制用户不受read_only参数的影响。
mysql-mmm架构总结: