MySQL的MMM高可用架构测试

 一、架构模式（双master零slave）
 
==============================================================
 
 
 
==============================================================
---------------------[1] mmm_common.conf ——————–
 
主机：
功能                                         IP                          主机名
monitor                                  192.168.9.159            proxy
DB     db1   Server-id=1          192.168.5.157           fbfldb01
         db2   Server-id=2          192.168.9.158           fbfldb02
虚拟ip：
IP0       192.168.9.154 (Write)
IP1       192.168.9.155 (Read)
IP2       192.168.9.156 (Read)
 
active_master_role writer
<host default>
cluster_interface eth0
pid_path /var/run/mysql-mmm/mmm_agentd.pid
bin_path /usr/libexec/mysql-mmm/
replication_user slave
replication_password slave
agent_user mmm_agent
agent_password RepAgent
</host>
<host db1>
ip 192.168.9.157
mode master
peer db2
</host>
<host db2>
ip 192.168.9.158
mode master
peer db1
</host>
#<host db3>
# ip 192.168.100.51
# mode slave
#</host>
<role writer>
hosts db1, db2 #能够作为writer的host
ips 192.168.100.250 #writer的虚拟IP，应用的写请求直接访问这里的ip即可
mode exclusive #只有两种模式：exclusive是排他，在这种模式下任何时候只能一个host拥有该角色，balanced模式下可以多个host同时拥有此角色。一般writer是ex，reader是ba
</role>
<role reader>
hosts db1, db2 #能够作为reader的host
ips 192.168.100.251, 192.168.100.252 #reader的虚拟IP，应用的读请求直接访问这里的ip即可
mode balanced
</role>
 
 
--------------------[2] mmm_mon.conf ———————–
include mmm_common.conf
<monitor>
ip 127.0.0.1
pid_path /var/run/mmm_mond.pid
bin_path /usr/lib/mysql-mmm/
status_path /var/lib/misc/mmm_mond.status
ping_ips 192.168.9.157, 192.168.9.158,192.168.9.254
</monitor>
<host default>
monitor_user mmm_monitor
monitor_password RepMonitor
</host>
debug 0
 
------------------------[4] mmm_agent.conf  ——————–
include mmm_common.conf
this db1 #在DB1上就写成这样，DB2上就写成this db2，写错了，将有一台DB的mysql-mmm-agent开不起来！切记！
 
查看状态：
[root@Proxy ~]# mmm_control show
db1(192.168.9.157) master/ONLINE. Roles: reader(192.168.9.156), writer(192.168.9.154)
db2(192.168.9.158) master/ONLINE. Roles: reader(192.168.9.155)
[root@Proxy ~]# mmm_control checks
db2 ping [last change: 2012/02/03 14:04:41] OK
db2 mysql [last change: 2012/02/03 14:04:41] OK
db2 rep_threads [last change: 2012/02/03 14:04:41] OK
db2 rep_backlog [last change: 2012/02/03 14:04:41] OK: Backlog is null
db1 ping [last change: 2012/02/03 14:04:41] OK
db1 mysql [last change: 2012/02/03 14:04:41] OK
db1 rep_threads [last change: 2012/02/03 14:04:41] OK
db1 rep_backlog [last change: 2012/02/03 14:04:41] OK: Backlog is null
[root@Proxy ~]# mmm_control mode
ACTIVE
 
模拟宕机切换：
随便找一个客户端，执行写操作:
@client[root@mysql-1 ~]# vi /usr/local/mysql/binlog/inserting-into-db.sh
#!/bin/bash
while true;
do
mysql -ufbdb_user -pJc7ech-fB-me -h192.168.9.154 --database= fbdb -e "insert into test values(null);"
sleep 1 ;
done;
[root@mysql-1 ~]# ./inserting-into-db.sh &
 
可以看到两个db中的binlog显示的server id都是1，也就是说当前情况下db1是作为写库。
停止db1
[root@fbfldb01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL.. SUCCESS!
立即恢复DB1后proxy上查看mmm集群状态
 
检查mmmDB1的日志：
[root@fbfldb01 binlog]# tail -f /var/log/mysql-mmm/mmm_agentd.log
2012/02/03 17:46:10 FATAL Couldn't allow 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:46:13 INFO We have some new roles added 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 的<role writer>中设置prefer=db1，这样在db1恢复正常之后，就可以再次被切换为写库了。
 
观察整个切换过程发现，切换过程花费了15S!