讀寫分離的三種方法-資料下載頁

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

　　

【正文】 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 如果已經安裝 會提示已經安裝 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/ ——————————–以下是我配置文件 內容 ——————————— 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 ———————————以上是我配置文件 內容 —————————— 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(。)自動轉到 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(。)自動轉到 db1 上 mysql+mmm+proxy 實現 mysql 讀寫分離及 HA MultiMaster Replication Manager for MySQL 動機 :proxy實現讀寫分離 MMM使 Replication方案具有 HA 下面先看從網上摘抄的一段說明。 引言 MasterSlave 的數據庫機構解決了很多問題，特別是 read/write比較高的 ： 寫操作全部在 Master結點執行，并由 Slave數據庫結點定時 (默認 60s)讀取 Master 的 binlog 將眾多的用戶讀請求分散到更多的數據庫節點，從而減輕了單點的壓力 這是對 Replication的最基本陳述，這種模式的在系統 Scaleout方案中很有引力 (如有必要，數據可以先進行 Sharding，再使用 replication)。 它的缺點是： Slave實時性的保障，對于實時性很高的場合可能需要做一些處理 高可用性問題， Master就是那個致命點 (SPOF:Single point of failure) 本文主要討論的是如何解決第 2 個缺點。 DB的設計對大規模、高負載的系統是極其重要的。高可用性 (High availability)在重要的系統(critical System)是需要架構師事先考慮的。存在 SPOF:Single point of failure 的設計在重要系統中是危險的。 MasterMaster Replication 使用兩個 MySQL數據庫 db01,db02，互為 Master和 Slave，即： 一邊 db01作為 db02的 master，一旦有數據寫向 db01時， db02定時從 db01更新 另一邊 db02也作為 db01的 master，一旦有數據寫向 db02時， db01也定時從 db02獲得更新 (這不會導致循環 ， MySQL Slave默認不會記錄 Master同步過來的變化 ) 但從 AppServer 的角度來說，同時只有一個結點 db01扮演 Master，另外一個結點 db02扮演Slave，不能同時兩個結點扮演 Master。即 AppSever 總是把 write操作分配某個數據庫 (db01)，除非 db01 failed，被切換。 如果扮演 Slave的數據庫結點 db02 Failed 了： a)此時 appServer要能夠把所有的 read,write分配給 db01， read操作不再指向 db02 b)一旦 db02恢復過來后，繼續充當 Slave角色，并告訴 AppServer可以將 read分配給它了 如果扮演 Master的數據庫結點 db01 Failed 了 a)此時 appServer要能夠把所有的寫操作從 db01切換分配給 db02，也就是切換 Master由 db02充當 b)db01恢復過來后，充當 Slave的角色， Master由 db02繼續扮演 難點： 4 要如何自動進行？ MasterMaster with n Slaves Replication ![if !vml] ![endif] 這比上一個還要復雜，即： 當一個 Master Fail 時，所有的 Slave不再從原來失敗的那個 Master(db01)獲取更新日志，而應該“自動”切換到最新充當 Master角色的數據庫 db02。 MMM， a greate project! MMM的基本信息請參考它的網站 (見后 參考資料 ) MMM有 3 個重要的器件 : mmmd_mon monitoring script which does all