or old rules deleted!
2012/02/03 17:46:13 INFO Deleted: reader(192.168.9.156), writer(192.168.9.154)
2012/02/03 17:46:13 FATAL Couldn't deny writes: ERROR: Can't connect to MySQL (host = 192.168.9.157:3306, user = mmm_agent)! Lost connection to MySQL server at 'reading initial communication packet', system error: 111
2012/02/03 17:59:48 INFO We have some new roles added or old rules deleted!
2012/02/03 17:59:48 INFO Added: reader(192.168.9.155)
2012/02/03 18:01:12 INFO We have some new roles added or old rules deleted!
从日志可以看出，db1停止之后，mmm提示connect error，由于当前的写库是db1，于是mmm认为db2上的数据已经不能和db1保持一致了，故把db2的读角色(reader)迁移到db1上。 变成了：
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 的中设置prefer=db1，这样在db1恢复正常之后，就可以再次被切换为写库了。
观察整个切换过程发现，切换过程花费了15S!
本文出自 “Centi.
Linux” 博客
|