MySQL的MMM高可用架构测试_MySQL
2020-11-09
来源：爱站旅游
==============================================================
==============================================================
---------------------[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
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
ip 192.168.9.157
mode master
peer db2
ip 192.168.9.158
mode master
peer db1
#
# ip 192.168.100.51
# mode slave
#
hosts db1, db2 #能够作为writer的host
ips 192.168.100.250 #writer的虚拟IP，应用的写请求直接访问这里的ip即可
mode exclusive #只有两种模式：exclusive是排他，在这种模式下任何时候只能一个host拥有该角色，balanced模式下可以多个host同时拥有此角色。一般writer是ex，reader是ba
hosts db1, db2 #能够作为reader的host
ips 192.168.100.251, 192.168.100.252 #reader的虚拟IP，应用的读请求直接访问这里的ip即可
mode balanced
--------------------[2] mmm_mon.conf ———————–
include mmm_common.conf
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_user mmm_monitor
monitor_password RepMonitor
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 的
观察整个切换过程发现，切换过程花费了15S!
本文出自 “Centi.Linux” 博客 bitsCN.com
显示全文