MySQL的MMM高可用架构测试_MySQL
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MySQL的MMM高可用架构测试_MySQL，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5291字，纯文字阅读大概需要8分钟。
内容图文
bitsCN.com
一、架构模式（双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
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
内容总结
以上是互联网集市为您收集整理的MySQL的MMM高可用架构测试_MySQL全部内容，希望文章能够帮你解决MySQL的MMM高可用架构测试_MySQL所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。
来源：【匿名】