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 的
中設置prefer=db1，這樣在db1恢復正常之后，就可以再次被切換為寫庫了。
觀察整個切換過程發現，切換過程花費了15S!
本文出自 “Centi.Linux” 博客 bitsCN.com
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
