【導讀】本代碼是從uchome的代碼修改的，是因為要解決uchome的效率而處理的。的希望提出相關(guān)的建議。有待以后不斷完善。。希望給有需要的朋友帶來幫助。

　　

【正文】 xamples/ /usr/local/mmm/etc/ shell vi /usr/local/mmm/etc/ ———————————以下是我 ——————————— MasterMaster Manager config (agent) Debug mode debug no Paths pid_path /usr/local/mmm/var/ bin_path /usr/local/mmm/bin Logging setup log mydebug file /usr/local/mmm/var/ level debug log mytraps file /usr/local/mmm/var/ level trap MMMD mand socket tcpport and ip bind_port 9989 Cluster interface cluster_interface eth0 Define current server id this db2 mode master For masters peer db1 Cluster hosts addresses and access params host db1 ip port 3306 user rep_agent password RepAgent host db2 ip port 3306 user rep_agent password RepAgent ———————————以上是我 ——————————— shell /usr/local/mmm/scripts/shell lsof i:9989 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME perl 2736 root 3u IPv4 7740 TCP *:9989 (LISTEN) 4. MOD 配置 : shell ln s /usr/local/mysql/bin/mysql_config /sbin/mysql_config shell ln s /usr/local/mysql/lib/mysql/ /usr/lib/ shell cpan Algorithm::Diff Proc::Daemon Time::HiRes DBI DBD::mysql shell yum y install iproute 如果已經(jīng)安裝 會提示已經(jīng)安裝 shell yum y install subversion shell svn checkout shell cd trunk shell perl shell cp /usr/local/mmm/etc/examples/ /usr/local/mmm/etc/ shell vi /usr/local/mmm/etc/ ——————————–以下是我配置文件 內(nèi)容 ——————————— MasterMaster Manager config (monitor) Debug mode debug no Paths pid_path /usr/local/mmm/var/ status_path /usr/local/mmm/var/ bin_path /usr/local/mmm/bin Logging setup log mydebug file /usr/local/mmm/var/ level debug log mytraps file /usr/local/mmm/var/ level trap MMMD mand socket tcpport bind_port 9988 agent_port 9989 monitor_ip Cluster interface cluster_interface eth0 Cluster hosts addresses and access params host db1 ip port 3306 user rep_monitor password RepMonitor mode master peer db2 host db2 ip port 3306 user rep_monitor password RepMonitor mode master peer db1 Define roles active_master_role writer Mysql Reader role role reader mode balanced servers db1, db2 ip , Mysql Writer role role writer mode exclusive servers db1, db2 ip Checks parameters Ping checker check ping check_period 1 trap_period 5 timeout 2 Mysql checker check mysql check_period 1 trap_period 2 timeout 2 Mysql replication backlog checker check rep_backlog check_period 5 trap_period 10 max_backlog 60 timeout 2 Mysql replication threads checker check rep_threads check_period 1 trap_period 5 timeout 2 ———————————以上是我配置文件 內(nèi)容 —————————— shell /usr/local/mmm/scripts/shell mmm_control set_online db1 讓 DB1 服務器上線 shell mmm_control set_online db2 讓 DB2 服務器上線 shell mmm_control show Config file: Daemon is running! Servers status: db1(): master/ONLINE. Roles: reader(。), writer(。) db2(): master/ONLINE. Roles: reader(。) 5. 設置開機自啟動 db1, db2 開機自啟動 shell cp /usr/local/mmm/scripts/shell chmod 700 /etc/shell chkconfig –add mmmd shell chkconfig –level 345 mmmd on Mon 開機自啟動 shell cp /usr/local/mmm/scripts/shell chmod 700 /etc/shell chkconfig –add mmm_mon shell chkconfig –level 345 mmm_mon on 6. mmm工作流程以及恢復方法 (1)當 db1服務器 down 機時 mon 會檢測到服務器 down 機并且把會把 reader(。), writer(。)自動轉(zhuǎn)到 db2 [root@localhost etc] mmm_control show Config file: Daemon is running! Servers status: db1(): master/HARD_OFFLINE. Roles: None db2(): master/ONLINE. Roles: reader(。), reader(。), writer(。) (2)當 db1上 線后 ,mon 會檢測到 ,并且把 reader(。), reader(。), writer(。)自動轉(zhuǎn)到 db1 上 mysql+mmm+proxy 實現(xiàn) mysql 讀寫分離及 HA MultiMaster Replication Manager for MySQL 動機 :proxy實現(xiàn)讀寫分離 MMM使 Replication方案具有 HA 下面先看從網(wǎng)上摘抄的一段說明。 引言 MasterSlave 的數(shù)據(jù)庫機構(gòu)解決了很多問題，特別是 read/write比較高的 ： 寫操作全部在 Master結(jié)點執(zhí)行，并由 Slave數(shù)據(jù)庫結(jié)點定時 (默認 60s)讀取 Master 的 binlog 將眾多的用戶讀請求分散到更多的數(shù)據(jù)庫節(jié)點，從而減輕了單點的壓力 這是對 Replication的最基本陳述，這種模式的在系統(tǒng) Scaleout方案中很有引力 (如有必要，數(shù)據(jù)可以先進行 Sharding，再使用 replication)。 它的缺點是： Slave實時性的保障，對于實時性很高的場合可能需要做一些處理 高可用性問題， Master就是那個致命點 (SPOF:Single point of failure) 本文主要討論的是如何解決第 2 個缺點。 DB的設計對大規(guī)模、高負載的系統(tǒng)是極其重要的。高可用性 (High availability)在重要的系統(tǒng)(critical System)是需要架構(gòu)師事先考慮的。存在 SPOF:Single point of failure 的設計在重要系統(tǒng)中是危險的。 MasterMaster Replication 使用兩個 MySQL數(shù)據(jù)庫 db01,db02，互為 Master和 Slave，即： 一邊 db01作為 db02的 master，一旦有數(shù)據(jù)寫向 db01時， db02定時從 db01更新 另一邊 db02也作為 db01的 master，一旦有數(shù)據(jù)寫向 db02時， db01也定時從 db02獲得更新 (這不會導致循環(huán) ， MySQL Slave默認不會記錄 Master同步過來的變化 ) 但從 AppServer 的角度來說，同時只有一個結(jié)點 db01扮演 Master，另外一個結(jié)點 db02扮演Slave，不能同時兩個結(jié)點扮演 Master。即 AppSever 總是把 write操作分配某個數(shù)據(jù)庫 (db01)，除非 db01 failed，被切換。 如果扮演 Slave的數(shù)據(jù)庫結(jié)點 db02 Failed 了： a)此時 appServer要能夠把所有的 read,write分配給 db01， read操作不再指向 db02 b)一旦 db02恢復過來后，繼續(xù)充當 Slave角色，并告訴 AppServer可以將 read分配給它了 如果扮演 Master的數(shù)據(jù)庫結(jié)點 db01 Failed 了 a)此時 appServer要能夠把所有的寫操作從 db01切換分配給 db02，也就是切換 Master由 db02充當 b)db01恢復過來后，充當 Slave的角色， Master由 db02繼續(xù)扮演 難點： 4 要如何自動進行？ MasterMaster with n Slaves Replication ![if !vml] ![endif] 這比上一個還要復雜，即： 當一個 Master Fail 時，所有的 Slave不再從原來失敗的那個 Master(db01)獲取更新日志，而應該“自動”切換到最新充當 Master角色的數(shù)據(jù)庫 db02。 MMM， a greate project! MMM的基本信息請參考它的網(wǎng)站 (見后 參考資料 ) MMM有 3 個重要的器件 : mmmd_mon monitoring script which does all