MySQL 高可用架構之MMM
簡介
MMM(Master-Master replication manager for MySQL)是一套支援雙主故障切換和雙主日常管理的指令碼程式。MMM使用Perl語言開發,主要用來監控和管理MySQL Master-Master(雙主)複製,雖然叫做雙主複製,但是業務上同一時刻只允許對一個主進行寫入,另一臺備選主上提供部分讀服務,以加速在主主切換時刻備選主的預熱,可以說MMM這套指令碼程式一方面實現了故障切換的功能,另一方面其內部附加的工具指令碼也可以實現多個slave的read負載均衡。
MMM提供了自動和手動兩種方式移除一組伺服器中複製延遲較高的伺服器的虛擬ip,同時它還可以備份資料,實現兩節點之間的資料同步等。由於MMM無法完全的保證資料一致性,所以MMM適用於對資料的一致性要求不是很高,但是又想最大程度的保證業務可用性的場景。對於那些對資料的一致性要求很高的業務,非常不建議採用MMM這種高可用架構。
下面我們通過一個實際案例來充分了解MMM的內部架構,如下圖所示。
具體的配置資訊如下所示:
角色 ip地址 主機名字 server-id monitoring 192.168.0.30 db2 - master1 192.168.0.60 db1 1 master2 192.168.0.50 db2 2slave1 192.168.0.40 db3 3
業務中的服務ip資訊如下所示:
ip地址 角色 描述 192.168.0.108 write 應用程式連線該ip對主庫進行寫請求 192.168.0.88 read 應用程式連線該ip進行讀請求 192.168.0.98 read 應用程式連線該ip進行讀請求
具體的配置步驟如下:
(1)主機配置
配置/etc/hosts,在所有主機中,新增所有的主機資訊:
[[email protected]192.168.0.30 ~]# cat /etc/hosts 192.168.0.60 db1 192.168.0.50 db2 192.168.0.40 db3 [[email protected]192.168.0.30 ~]#
(2)首先在3臺主機上安裝mysql和搭建複製(192.168.0.60和192.168.0.50互為主從,192.168.0.40為192.168.0.60的從)具體的複製搭建這裡就省略,要是這都不會,那麼該文章對你就沒意思了。然後在每個mysql的配置檔案中加入以下內容,注意server_id 不能重複。
db1(192.168.0.60)上:
server-id = 1 log_slave_updates = 1 auto-increment-increment = 2 auto-increment-offset = 1
db2(192.168.0.50)上:
server-id = 2 log_slave_updates = 1 auto-increment-increment = 2 auto-increment-offset = 2
db3(192.168.0.40)上:
server-id = 3 log_slave_updates = 1
上面的id不一定要按順序來,只要沒有重複即可。
(3)安裝MMM所需要的Perl模組(所有伺服器)執行該指令碼,也可以安裝epel源,然後yum -y install mysql-mmm*來安裝MMM:
rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm yum -y install mysql-mmm*
[[email protected]192.168.0.60 ~]# cat install.sh #!/bin/bash wget http://xrl.us/cpanm --no-check-certificate mv cpanm /usr/bin chmod 755 /usr/bin/cpanm cat > /root/list << EOF install Algorithm::Diff install Class::Singleton install DBI install DBD::mysql install File::Basename install File::stat install File::Temp install Log::Dispatch install Log::Log4perl install Mail::Send install Net::ARP install Net::Ping install Proc::Daemon install Thread::Queue install Time::HiRes EOF for package in `cat /root/list` do cpanm $package done [[email protected]192.168.0.60 ~]#
(4)
下載mysql-mmm軟體,在所有伺服器上安裝:
[[email protected]192.168.0.60 ~]# wget http://mysql-mmm.org/_media/:mmm2:mysql-mmm-2.2.1.tar.gz
[[email protected]192.168.0.60 ~]# mv :mmm2:mysql-mmm-2.2.1.tar.gz mysql-mmm-2.2.1.tar.gz [[email protected]192.168.0.60 ~]# tar xf mysql-mmm-2.2.1.tar.gz [[email protected]192.168.0.60 ~]# cd mysql-mmm-2.2.1 [[email protected]192.168.0.60 mysql-mmm-2.2.1]# make install
mysql-mmm安裝後的主要拓撲結構如下所示(注意:yum安裝的和原始碼安裝的路徑有所區別):
目錄 介紹 /usr/lib/perl5/vendor_perl/5.8.8/MMM MMM使用的主要perl模組 /usr/lib/mysql-mmm MMM使用的主要指令碼 /usr/sbin MMM使用的主要命令的路徑 /etc/init.d/ MMM的agent和monitor啟動服務的目錄 /etc/mysql-mmm MMM配置檔案的路徑,預設所以的配置檔案位於該目錄下 /var/log/mysql-mmm 預設的MMM儲存日誌的位置
到這裡已經完成了MMM的基本需求,接下來需要配置具體的配置檔案,其中mmm_common.conf,mmm_agent.conf為agent端的配置檔案,mmm_mon.conf為monitor端的配置檔案。
(5)配置agent端的配置檔案,需要在db1,db2,db3上分別配置。
在db1主機上配置agent配置檔案:
[[email protected]192.168.0.60 ~]# cd /etc/mysql-mmm/ [[email protected]192.168.0.60 mysql-mmm]# cat mmm_common.conf active_master_role writer <host default> cluster_interface eth1 pid_path /var/run/mmm_agentd.pid bin_path /usr/lib/mysql-mmm/ replication_user repl replication_password 123456 agent_user mmm_agent agent_password mmm_agent </host> <host db1> ip 192.168.0.60 mode master peer db2 </host> <host db2> ip 192.168.0.50 mode master peer db1 </host> <host db3> ip 192.168.0.40 mode slave </host> <role writer> hosts db1, db2 ips 192.168.0.108 mode exclusive </role> <role reader> hosts db2, db3 ips 192.168.0.88, 192.168.0.98 mode balanced </role> [[email protected]192.168.0.60 mysql-mmm]#
其中replication_user用於檢查複製的使用者,agent_user為agent的使用者,mode標明是否為主或者備選主,或者從庫。mode exclusive主為獨佔模式,同一時刻只能有一個主,<role write>中hosts表示目前的主庫和備選主的真實主機ip或者主機名,ips為對外提供的虛擬機器ip地址,<role readr>中hosts代表從庫真實的ip和主機名,ips代表從庫的虛擬ip地址。
由於db2和db3兩臺主機也要配置agent配置檔案,我們直接把mmm_common.conf從db1拷貝到db2和db3兩臺主機的/etc/mysql-mmm下。
注意:monitor主機要需要:
scp /etc/mysql-mmm/mmm_common.conf db2:/etc/mysql-mmm/
scp /etc/mysql-mmm/mmm_common.conf db3:/etc/mysql-mmm/
分別在db1,db2,db3三臺主機的/etc/mysql-mmm配置mmm_agent.conf檔案,分別用不同的字元標識,注意這三臺機器的this db1這塊要想,比如本環境中,db1要配置this db1,db2要配置為this db2,而db3要配置為this db3。
在db1(192.168.0.60)上:
[[email protected]192.168.0.60 ~]# cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db1 [[email protected]192.168.0.60 ~]#
在db2(192.168.0.50)上:
[[email protected]192.168.0.50 ~]# cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db2 [[email protected]192.168.0.50 ~]#
在db3(192.168.0.40)上:
[[email protected]192.168.0.40 ~]# cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db3 [[email protected]192.168.0.40 ~]#
在db2(192.168.0.30)配置monitor的配置檔案:
[[email protected]192.168.0.30 ~]# cat /etc/mysql-mmm/mmm_mon.conf include mmm_common.conf <monitor> ip 127.0.0.1 pid_path /var/run/mysql-mmm/mmm_mond.pid bin_path /usr/libexec/mysql-mmm status_path /var/lib/mysql-mmm/mmm_mond.status ping_ips 192.168.0.40,192.168.0.50,192.168.0.60 auto_set_online 60 </monitor> <host default> monitor_user mmm_monitor monitor_password mmm_monitor </host> debug 0 [[email protected]192.168.0.30 ~]#
這裡只在原有配置檔案中的ping_ips添加了整個架構被監控主機的ip地址,而在<host default>中配置了用於監控的使用者。
(6)建立監控使用者,這裡需要建立3個監控使用者,具體描述如下:
使用者名稱 描述 許可權
monitor user MMM的monitor端監控所有的mysql資料庫的狀態使用者 REPLICATION CLIENT
agent user 主要是MMM客戶端用於改變的master的read_only狀態使用者 SUPER,REPLICATION CLIENT,PROCESS
repl 用於複製的使用者 REPLICATION SLAVE
在3臺伺服器(db1,db2,db3)進行授權,因為我之前的主主複製,以及主從已經是ok的,所以我在其中一臺伺服器執行就ok了。用於複製的賬號之前已經有了,所以這裡就授權兩個賬號。
mysql> GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'192.168.0.%' IDENTIFIED BY 'mmm_agent'; Query OK, 0 rows affected (0.08 sec) mysql> GRANT REPLICATION CLIENT ON *.* TO 'mmm_monitor'@'192.168.0.%' IDENTIFIED BY 'mmm_monitor'; Query OK, 0 rows affected (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.03 sec) mysql>
如果是從頭到尾從新搭建,則加上另外一個複製賬戶(分別在3臺伺服器都需要執行這3條SQL):
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.%' IDENTIFIED BY '123456';
(7)啟動agent服務。
最後分別在db1,db2,db3上啟動agent,並在db2(192.168.0.30)上啟動monitor程式:
[[email protected]192.168.0.60 ~]# /etc/init.d/mysql-mmm-agent start Daemon bin: '/usr/sbin/mmm_agentd' Daemon pid: '/var/run/mmm_agentd.pid' Starting MMM Agent daemon... Ok [[email protected]192.168.0.60 ~]#
[[email protected]192.168.0.50 ~]# /etc/init.d/mysql-mmm-agent start Starting MMM Agent Daemon: [ OK ] [[email protected]192.168.0.50 ~]#
因為我有些使用yum安裝的,所以啟動資訊有些不一樣。^_^
[[email protected]192.168.0.40 ~]# /etc/init.d/mysql-mmm-agent start Starting MMM Agent Daemon: [ OK ] [[email protected]192.168.0.40 ~]#
啟動monitor:
[[email protected]192.168.0.30 ~]# /etc/init.d/mysql-mmm-monitor start Starting MMM Monitor Daemon: [ OK ] [[email protected]192.168.0.30 ~]#
其中agent的日誌存放在/var/log/mysql-mmm/mmm_agentd.log,monitor日誌放在/var/log/mysql-mmm/mmm_mond.log,啟動過程中有什麼問題,通常日誌都會有詳細的記錄。
(8)在monitor主機上檢查叢集主機的狀態:
[[email protected]192.168.0.30 ~]# mmm_control checks all db2 ping [last change: 2014/04/18 00:29:01] OK db2 mysql [last change: 2014/04/18 00:29:01] OK db2 rep_threads [last change: 2014/04/18 00:29:01] OK db2 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null db3 ping [last change: 2014/04/18 00:29:01] OK db3 mysql [last change: 2014/04/18 00:29:01] OK db3 rep_threads [last change: 2014/04/18 00:29:01] OK db3 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null db1 ping [last change: 2014/04/18 00:29:01] OK db1 mysql [last change: 2014/04/18 00:29:01] OK db1 rep_threads [last change: 2014/04/18 00:29:01] OK db1 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null [[email protected]192.168.0.30 ~]#
(9)在monitor主機上檢查叢集環境線上狀況:
[[email protected]192.168.0.30 ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected]192.168.0.30 ~]#
(10)online(上線)所有主機:
我這裡主機已經線上了,如果沒有線上,可以使用下面的命令將相關主機online
[[email protected]192.168.0.30 ~]# mmm_control set_online db1 OK: This host is already ONLINE. Skipping command. [[email protected]192.168.0.30 ~]#
提示主機已經線上,已經跳過命令執行了。
到這裡整個叢集就配置完成了。從輸出中可以看到虛擬ip 192.168.0.108已經順利新增到主機192.168.0.60上作為主對外提供寫服務,虛擬ip 192.168.0.88新增到主機192.168.0.50上對外提供讀服務,而虛擬ip 192.168.0.98新增到192.168.0.40上對外提供讀服務。
MMM高可用測試
我們已經完成高可用環境的搭建了,下面我們就可以做MMM的HA測試咯。首先檢視整個叢集的狀態,可以看到整個叢集狀態正常。
[[email protected]192.168.0.30 ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected]192.168.0.30 ~]#
模擬db2(192.168.0.50 )宕機,手動停止mysql服務,觀察monitor日誌:
[[email protected]192.168.0.30 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log 2014/04/18 00:55:53 FATAL State of host 'db2' changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK)
從日誌發現db2的狀態有ONLINE轉換為HARD_OFFLINE
重新檢視叢集的最新狀態:
[[email protected]192.168.0.30 ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/HARD_OFFLINE. Roles: db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.88), reader(192.168.0.98) [[email protected]192.168.0.30 ~]#
重啟db2,可以看到db2由HARD_OFFLINE轉到AWAITING_RECOVERY。這裡db2再次接管讀請求。
[[email protected]192.168.0.30 ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected]192.168.0.30 ~]#
模擬db1主庫宕機:
檢視叢集狀態:
[[email protected]192.168.0.30 ~]# mmm_control show db1(192.168.0.60) master/HARD_OFFLINE. Roles: db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88), writer(192.168.0.108) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected]192.168.0.30 ~]#
檢視MMM日誌:
[[email protected]192.168.0.30 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log 2014/04/18 01:09:20 FATAL State of host 'db1' changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK)
從上面可以發現,db1由以前的ONLINE轉化為HARD_OFFLINE,移除了寫角色,因為db2是備選主,所以接管了寫角色,db3指向新的主庫db2,應該說db3實際上找到了db2的sql現在的位置,即db2 show master返回的值,然後直接在db3上change master to到db2。
db1,db2,db3之間為一主兩從的複製關係,一旦發生db2,db3延時於db1時,這個時刻db1 mysql宕機,db3將會等待資料追上db1後,再重新指向新的主db2,進行change master to db2操作,在db1宕機的過程中,一旦db2落後於db1,這時發生切換,db2變成了可寫狀態,資料的一致性將會無法保證。
總結:
MMM不適用於對資料一致性要求很高的環境。但是高可用完全做到了。
參考資料:
相關推薦
MySQL 高可用架構之MMM
簡介 MMM(Master-Master replication manager for MySQL)是一套支援雙主故障切換和雙主日常管理的指令碼程式。MMM使用Perl語言開發,主要用來監控和管理MySQL Master-Master(雙主)複製,雖然叫做雙主複製,但是業務上同一時刻只允許對一個主進行寫入
MySQL雙主高可用架構之MMM實戰
MMM簡介: MMM即Master-Master Replication Manager for MySQL(mysql主主複製管理器),是關於mysql主主複製配置的監控、故障轉移和管理的一套可伸縮的指令碼套件(在任何時候只有一個節點可以被寫入),這個套件也能基於標準
MySQL高可用架構之MHA
mysql1、關於MHAMHA(Master HA)是一款開源的MySQL的高可用程序,它為MySQL主從復制架構提供了automating master failover功能。MHA在監控到master節點故障時,會提升其中擁有的最新數據的slave節點成為新的master節點,在此期間,MHA會通過其它從
MySQL高可用架構之MySQL5.7.19 PXC
mysql高可用 5.7 sta var show mysql clu -- ike mysql> show global status like ‘wsrep_cluster_size‘;+--------------------+-------+| Variabl
互聯網金融MySQL高可用架構之-MHA故障切換
文件 ads erro osi ddr app1 bind enabled ive 互聯網金融MySQL高可用架構之-MHA 在線平滑切換過程 --切換命令如下: [root@MHA bin]# masterha_master_switch --conf=/etc/app1
MySQL高可用架構之基於MHA的搭建
MySQL高可用架構之基於MHA的搭建 一、MySQL MHA架構介紹: MHA(Master High Availability)目前在MySQL高可用方面是一個相對成熟的解決方案,它由日本DeNA公司youshimaton(現就職於Facebook公司)開發,是一套
mysql高可用架構之MHA和mysql日誌優化
一、MHA簡介: MHA(Master High Availability)目前在MySQL高可用方面是一個相對成熟的解決方案,它由日本DeNA公司youshimaton(現就職於 Facebook公司)開發,是一套優秀的作為MySQL高可用性環境下故障切換和主從提升的高可用軟體。在M
MySQL高可用架構之MHA搭建以及測試(二)
一、MHA特點 MHA監控複製架構的主伺服器,一旦檢測到主伺服器故障,就會自動進行故障轉移。 即使有些從伺服器沒有收到最新的relay log,MHA自動從最新的從伺服器上識別差異的relay log並把這些日誌應用到其他從伺服器上,因此所有的從伺服器保持一致性了。MHA通
mysql實現高可用架構之MHA
行數據 reading glob restart 比較 實驗 是否 其余 one 一、簡介 MHA(Master HA)是一款開源的 MySQL 的高可用程序,它為 MySQL 主從復制架構提供了 automating master failover 功能。MHA 在監
MySQL/MariaDB高可用架構之MHA
宣告:本次實驗使用的是MariaDB資料庫,所以本文中所出現的MariaDB與MySQL都是指的是MariaDB!!! MHA(Master HA)是一款開源的 MySQL 的高可用程式,它為 MySQL主從複製架構提供 了 automating master
mysql高可用架構mha之master_ip_failover腳本
warnings ddr long HERE eat code ida val nbsp 腳本如下: #!/usr/bin/env perl use strict; use warnings FATAL => ‘all‘; u
京東618:商城交易平臺的高可用架構之路
資源 系統 定位問題 修復 tle 峰值 網絡 寫入 差異 據騰訊科技報道,6月18日零點,京東全民年中購物節拉開了高潮的序幕。第一個小時的銷售額超過去年同期的250%。從淩晨開始的海量訂單讓6月1日就拉開序幕的京東年中購物節奏出最強音,大量用戶瞬間湧入,峰值訂單被不斷刷新
詳解 MySQL 高可用群集,MMM搭建高可用
cti 主從復制 防火墻 操作系統 oracl pat -- utf8 set 目錄: 1·MMM 簡介2·MMM 各個角色說明3·案例環境介紹4·案例實施5·總結 一:MMM 簡介: 1)MMM 是什麽:說得簡單點,就是 MySQL 主主復制的管理器。之前的一篇文
MySql 高可用架構Atlas
stop creat st2 正常 utf8 spa key target box Atlas是由 Qihoo 360公司Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基礎上,修改了
MySQL高可用架構-MHA環境部署記錄
一、MHA介紹 1 2 3
MySQL高可用架構設計(主從複製)
1、MySQL複製功能提供分擔讀負載 複製解決了什麼問題? 1、 實現在不同伺服器上的資料分佈 利用二進位制日誌增量進行
MySQL高可用方案之DRBD+MySQL+RHCS(下)
續:MySQL高可用方案之DRBD+MySQL+RHCS(上) 五、MySQL5.6.42安裝 安裝步驟(兩臺機器都要安裝) [[email protected] ~]# cd /opt/ [[email protected] opt]# ls mysql-5.6.42-linux
MySQL高可用方案之DRBD+MySQL+RHCS(上)
MySQL作為最流行的資料庫,它的高可用方案也是多種多樣,其中用的比較多的是MHA+增強版半同步。但是客戶使用的是DRBD+RHCS的方案,通過各方尋找安裝資料,最終形成一個完整的安裝文件,供參考 一、DRBD介紹 1.1 DRBD基本功能 Distributed Replicated Block De
Mysql高可用架構——MHA
MHA(Master High Availability)什麼是資料庫的高可用性呢??資料庫主機中我們會有做成主從關係的或者其他關係型資料庫,如果主掛了,不會影響資料的訪問,假如是一主三從架構,主庫掛了,但主庫能被從庫ssh上去的情況下,MHA從三個從庫中選擇同步最接近的作為
高可用架構之高可用的應用和服務
高可用的網站架構需要網站應用每個層面的支援,本文著重介紹應用層和服務層的高可用的解決方案。 1、高可用的應用 應用層主要處理網站應用的業務邏輯,因此有時也被稱作業務邏輯層,應用的一個顯著特點是應用的無狀態性。 所謂無狀態的應用是指應用伺服器不儲存業務的上下文資訊,而僅根據