MySQL的MMM高可用架构测试(3)

  db1(192.168.9.157) master/ONLINE. Roles: reader(192.168.9.155)
  db2(192.168.9.158) master/ONLINE. Roles: reader(192.168.9.156), writer(192.168.9.154）
但是，若DB1未立即恢复工作，mmm的”mysql”检查项在10秒后出现报警，认为db1已经彻底失败，因此会把db1设置状态为hard_offline，把db2从replication_fail状态切换到online状态（因为db2的mysql至少还活着）同时把上面的所有角色切换到db2上。状态最 终变为:
[root@Proxy mysql-mmm]# mmm_control show
db1(192.168.9.157) master/HARD_OFFLINE. Roles:
db2(192.168.9.158) master/ONLINE. Roles: reader(192.168.9.155), reader(192.168.9.156), writer(192.168.9.154)
 
很显然，当DB1或DB2中的其中一台宕机之后，mmm都会立即将宕机的主机的角色全部转换到另一台DB。
仔细分析Mmm的处理步骤大致是：
db1的“mysql”check恢复正常，然后把db1切换到awaiting_recovery状态。然后mmm判断db6的宕机时间在正常范围内，不属于异常情况，因此自动切换为online状态。
把db2中的一个reader角色迁移到db1上。
目前写库是db2。
注：可以在exclusive 的<role writer>中设置prefer=db1，这样在db1恢复正常之后，就可以再次被切换为写库了。
 
观察整个切换过程发现，切换过程花费了15S!
 
 
本文出自 “Centi.Linux” 博客