版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
基于Pacemaker+MHA的MySQL高可用實踐n
曾經(jīng)的MySQL
HA方案n
如何防止腦裂和數(shù)據(jù)丟失n
實現(xiàn)方式的選擇n
基于Pacemaker實現(xiàn)MySQL
HAn
雙節(jié)點零數(shù)據(jù)丟失HA方案2曾經(jīng)的MySQL
HA方案應(yīng)用write_vip主機(jī)備機(jī)Keepalived(主)Keepalived(備)MHA?Manager(備)MHA?Manager(主)MySQL(Master)MySQL(Slave)Binglog復(fù)制3存在的問題n
主備之間的網(wǎng)絡(luò)出現(xiàn)故障時,集群腦裂,導(dǎo)致數(shù)據(jù)雙寫,VIP來回切換。分區(qū)1分區(qū)2write_vipwrite_vip主機(jī)(舊)(
)主機(jī)
新Keepalived(主)Keepalived(主)MHA?Manager(主)MHA?Manager(主)MySQL(Master)MySQL(Master)教訓(xùn):KeepAlived不適合做有狀態(tài)服務(wù)的HA4n
蘇寧曾經(jīng)的MySQL
HA方案n
如何防止腦裂和數(shù)據(jù)丟失n
實現(xiàn)方式的選擇n
基于Pacemaker實現(xiàn)MySQL
HAn
雙節(jié)點零數(shù)據(jù)丟失HA方案5如何防止腦裂和數(shù)據(jù)丟失如何實現(xiàn)
?高可用抗腦裂零數(shù)據(jù)丟失6方法一:Quorum或第3方?jīng)_裁n
基本可解決腦裂問題,但應(yīng)用仍有機(jī)會訪問到舊Master并寫入數(shù)據(jù)。分區(qū)1分區(qū)2(with
Quorum)應(yīng)用1應(yīng)用2仲裁者write_vipMySQL(新Master)MySQL(舊Master)7方法二:故障節(jié)點隔離n
采用物理fence設(shè)備不通用,不易部署,可靠性也值得懷疑。n
引入中間層proxy,所有流量必須經(jīng)過proxy,由proxy隔離故障節(jié)點流量。增加復(fù)雜性,有性能損失,還要考慮proxy的高可用。n
每個節(jié)點上部署Agent,發(fā)現(xiàn)本節(jié)點已非合法Master,自行停止?;究尚?。但不能處理OS
hang住的情況,可能存在時間差。并且Agent也可能出故障。8方法三:舊Master自行拒絕寫入n
設(shè)置超大的MySQL半同步復(fù)制降級為異步復(fù)制的超時時間(比如300天),阻止脫離集群的舊Master寫入數(shù)據(jù)。9最終方案:組合拳n
3節(jié)點選主n
失去Quorum的分區(qū)自行釋放資源n
強制半同步3節(jié)點最多只能形成1組半同步復(fù)制關(guān)系,所以可以完全杜絕數(shù)據(jù)丟失和雙寫。Masteragentrpl_semi_sync_master_enabled=1rpl_semi_sync_master_timeout=25920000000rpl_semi_sync_slave_enabled=1rpl_semi_sync_master_wait_no_slave=1半同步復(fù)制半同步復(fù)制SlaveSlaveagentagent10完整的架構(gòu):增加讀寫分離n
1主N從(N>=2)n
半同步復(fù)制+異步復(fù)制n
基于VIP的訪問路由n
基于LVS的讀負(fù)載均衡應(yīng)用Read/WriteReadwrite_vipMaster異步復(fù)制異步復(fù)制半同步復(fù)制半同步復(fù)制Slaveread_vipLV
SSlaveSlaveSlave…read_only=1只讀節(jié)點(0個或多個)HA節(jié)點(3個)11n
曾經(jīng)的MySQL
HA方案n
如何防止腦裂和數(shù)據(jù)丟失n
實現(xiàn)方式的選擇n
基于Pacemaker實現(xiàn)MySQL
HAn
雙節(jié)點零數(shù)據(jù)丟失HA方案12實現(xiàn)方式1:
Zookeeper
+Monitor
+Agent
+
MHAn
Zookeeper存儲集群狀態(tài)和選主n
Monitor集群控制n
Agent做健康監(jiān)視和命令執(zhí)行n
MHA做實際的failover(包含日志補償)優(yōu)點:n
靈活可控缺點:n
缺少完整的集群管理,一切都要自己實現(xiàn)。13實現(xiàn)方式2:
Pacemaker
+
定制Agent
+MHAn
Pacemaker
+
Corosync統(tǒng)一進(jìn)行資源管理n
資源Agent監(jiān)視各類資源n
MHA做實際的failover(包含日志補償)優(yōu)點:n
通用成熟的集群套件n
各個資源互相獨立并可通過配置靈活組合缺點:n
定制開發(fā)的學(xué)習(xí)成本高最終的選擇:不重復(fù)發(fā)明輪子14曾經(jīng)考慮過的其它方案n
Galera
Cluster性能損耗太大,
不易擴(kuò)展,一些功能上的限制。n
MySQL
Fabric?不能解決數(shù)據(jù)丟失和數(shù)據(jù)一致的問題,
并且要考慮Fa
bri
c
本身的高可用。15n
曾經(jīng)的MySQL
HA方案n
如何防止腦裂和數(shù)據(jù)丟失n
實現(xiàn)方式的選擇n
基于Pacemaker實現(xiàn)MySQL
HAn
雙節(jié)點零數(shù)據(jù)丟失HA方案16Pacemaker簡介(1/2)Pacemaker+
Corosync是目前Linux下的首選集群套件(RHEL7里已經(jīng)取代了RHCS),已被包含在主流Linux發(fā)行版中。功能特性n節(jié)點管理增加,刪除,Standby,?Online資源管理start,stop,?promote,demote,?unmanage,?manage,?cleanup資源約束location?,?colocation
,?Order,?Group,?Clone,?Multi-state配置管理erase,?edit,save,loadnnnnn(Resource?Agent)資源擴(kuò)展OCF,?LSB,??systemd,?Upstart,?System?Services,?STONITHNotificationSNMP,Email,?External-AgentUtilization?and?Placement腦裂防護(hù)nnquorum或
資源搶占nnSTONITH(?Shoot-The-Other-Node-In-The-Head?)Multi-Site?Clusters17Pacemaker簡介(2/2)核心組件?
CIB?(aka.?Cluster?Information?Base)??
CRMd(aka.?Cluster?Resource?Management?daemon)??
LRMd
(aka.
?Local?Resource?Manag
ement?daemon)??
PEngine(aka.?PE?or?Policy?Engine)??
STONITHd主要外部組件?
Corosync?
Resource?Agents?
crmsh/pcsheartbeat已廢棄18為保證數(shù)據(jù)一致性和部署的靈活性,沒有采用ClusterLabs開源項目自帶的mysql和ldirectord
RA。實現(xiàn)架構(gòu)n
新開發(fā)MySQL和LVS的Resource
Agent進(jìn)行資源監(jiān)控n
每個節(jié)點部署MHA
node做實際的failovern
通過約束使寫VIP和Master動態(tài)綁定,讀VIP+LVS和Slave動態(tài)綁定colocation?write-vip-with-master?inf:?vip-write?msMysql:Mastercolocation?lvsdr-with-slave?inf:?lvsdrmsMysql:Slavecolocation?read-vip-with-lvsdrinf:?vip-read?lvsdrwrite_vip新開發(fā)的RAread_viplvsdr…mysql(s)mysql(m)mysql(s)mysql(s)MHAMHAMHAMHAPacemakerCorosync…HostHostHostHost19主從切換流程mysql
RA檢出mysqlmaster資源故障Corosync檢出mysqlmaster節(jié)點故障人工發(fā)起在線切換更新集群CIB由于是強制半同步并有日志補償,所以提升任何一個Slave節(jié)點作為新Master都不會丟失數(shù)據(jù)!Pengine計算集群最佳狀態(tài)CRMd發(fā)起主從切換Mysql
Resource
Agentmysq:promote()原主活判斷原主死活原主死m(xù)asterha_master_switch
--master_state=dead
…masterha_master_switch
--master_state=alive
…更新master信息20腦裂和數(shù)據(jù)丟失的防護(hù)n
不能獲得法定票數(shù)的分區(qū)上停止所有資源no-quorum-policy="stop“n
限定Master在指定的3個HA節(jié)點上分配location
loc-mysql-master
msMysql
\rule
$id="loc-mysql-master-rule"
$role="Master"
-inf:
#uname
ne
${node1}
and
#uname
ne
${node2}
and
#uname
ne
${node3}location
loc-mysql-master-2
msMysql
\rule
$id="loc-mysql-master-2-rule"
$role="Master"
10000:
#uname
eq
${node1}
or
#uname
eq
${node2}
or
#uname
eq
${node3}n
實施故障切換前,檢查本分區(qū)是否包含2個以上的HA節(jié)點,如否放棄切換。分區(qū)1分區(qū)2Master阻止其升級為MasterSlaveSlaveSlaveSlaveHA節(jié)點(3個)只讀節(jié)點(2個)21故障節(jié)點隔離(1/3)n
記錄包含切換次數(shù)和master節(jié)點名的master信息,阻止master信息不一致的節(jié)點(比如舊Master)上線。master信息源
存放位置內(nèi)容集群CIB本地文件MySQL//crm_config/mysql_replication/master_info
${切換次數(shù)}_${master節(jié)點名}/opt/mysql_ha/etc/master_infoshow
slave
status->Master_Host${切換次數(shù)}_${master節(jié)點名}主節(jié)點:空從節(jié)點:${master節(jié)點名}22故障節(jié)點隔離(2/3)n
阻止MySQL運行中物理機(jī)或OS發(fā)生crash的節(jié)點上線MySQL
5.5的Slave不支持crash
safe;一些系統(tǒng)也沒有把Master配置成crash
safe
(innodb_flush_log_at_trx_commit=1,sync_binlog=1)。當(dāng)物理機(jī)或OS
crash后,該節(jié)點可能和其它節(jié)點的數(shù)據(jù)不一致,必須阻止這樣的節(jié)點自動上線。23故障節(jié)點隔離(3/3)n
設(shè)置合理的遷移閾值,限制故障資源在原節(jié)點上重試的次數(shù)primitive
mysql
ocf:heartbeat:mysql
\…meta
migration-threshold=“3“24LVS的自動托管n
lvsdr
和mysql的Slave角色動態(tài)綁定colocation?lvsdr-with-slave?inf:?lvsdrmsMysql:Slaven
lvsdr根據(jù)mysql
slave的復(fù)制健康狀況動態(tài)更新LVSNode1:write_vipMaster半同步復(fù)制半同步復(fù)制Node2:Node3:read_vipLVSlvsdrSlaveSlave2)lvsdr監(jiān)視CIB中記錄的slave狀態(tài),利用ipvsadm動態(tài)更新LVS配置mysqlmysql1)
監(jiān)視slave的復(fù)制狀況并更新到集群CIB1)
監(jiān)視slave的復(fù)制狀況并更新到集群CIBCIBnode3:node2:Slave_IO_ThreadSlave_SQL_Thread
:?YesSecs_Behind_Master
:0Slave_IO_Thread:?
Yes???????:?
Yes???????Slave_SQL_Thread
:?YesSecs_Behind_Master
:025[root@srdsdevapp69?
mysql_ha]#?
./show_status.sh============Last?updated:?Fri?Jan??8?10:06:47?2016Last?change:?Fri?Jan??8?09:22:18?2016?via?crmd
on?srdsdevapp69Stack:?openais集群管理n
直接使用Pacemaker的CUI工具有諸多不便,因此基于crmsh包裝了一套簡單易用的集群管理腳本。Current?DC:?srdsdevapp69?
-
partition?with?quorumVersion:?1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d143?Nodes?
configured,?3?expected?votes9?Resources?
configured.============ü
start_all_resources.shü
stop_all_resources.shü
show_status.shOnline:?[?srdsdevapp71?
srdsdevapp73?srdsdevapp69?
]vip-writelvsdrvip-read(ocf::heartbeat:IPaddr2):
Started?srdsdevapp69(ocf::heartbeat:lvsdr):
Started?srdsdevapp71(ocf::heartbeat:IPaddr2):
Started?srdsdevapp71Master/Slave?
Set:?
msMysql
[mysql]Masters:?
[?
srdsdevapp69?
]Slaves:?
[?
srdsdevapp71?
srdsdevapp73?
]Clone?Set:?clone-lvsdr-realsvr
[lvsdr-realsvr]Started:?[?srdsdevapp73?srdsdevapp71?
]Stopped:?[?lvsdr-realsvr:2?]üonline_switch.shü
standby_node.shü
online_node.shNode?Attributes:ü
unmanage_all_resources.shü
manage_all_resources.shcleanup_all.sh*?Node?srdsdevapp71:+?Secs_Behind_Master+?
Sl
ave_IO_Thread:?0?????????:?Yes?
??????:?Yes?
??????:?10????????+?
Sl
ave_SQL_Thread+?master-mysql:1?
?????????????????*?Node?srdsdevapp73:+?Secs_Behind_Master+?
Sl
ave_IO_Threadü:?0?????????:?Yes?
??????:?Yes?
??????:?10????????+?
Sl
ave_SQL_Thread+?master-mysql:2?
?????????????????*?Node?srdsdevapp69:+?master-mysql:0?
?????????????????:?1000?26Failover測試RT化通過連續(xù)的RT測試,檢出很多偶發(fā)性的問題,尤其在網(wǎng)絡(luò)閃斷場景下。測試的故障類型:1.
MySQL進(jìn)程
crash2.
MySQL數(shù)據(jù)目錄損壞3.
OSreboot4.
節(jié)點網(wǎng)絡(luò)切斷5.
節(jié)點網(wǎng)絡(luò)閃斷(1~30秒)6.
Slave發(fā)生上述故障7.
…測試機(jī)1.
環(huán)境設(shè)置Read/Write2.
啟動后臺數(shù)據(jù)庫寫入腳本3.
制造故障SSH連接制造故障write_vipMaster4.
檢查failover成敗5.
檢查LVS更新6.
檢查數(shù)據(jù)丟失7.
恢復(fù)故障8.
測試下一個故障9.
循環(huán)測試下一輪(24小時不間斷)Read半同步復(fù)制半同步復(fù)制read_vipLVSSlaveSlave27踩過的坑n
Pacemaker
1.1.7的bug非常多解決辦法:升級為1.1.14。n
mysqld_safe自動重啟mysql進(jìn)程和Pacemaker的調(diào)度沖突解決辦法:改用mysqld。n
HA
Slave節(jié)點也設(shè)置了rpl_semi_sync_master_enabled=1,導(dǎo)致MHA做日志補償時hang住。解決辦法:調(diào)用MHA前臨時設(shè)置rpl_semi_sync_master_enabled=0,補償后再恢復(fù)。n
MHA中也有對舊Master的生死判斷,由于時間差以及判斷邏輯的差異,判斷結(jié)果和Pacemaker可能不一致,引發(fā)其它故障。解決辦法:
調(diào)用MHA前通過防火墻臨時阻斷MHA切換腳本到舊Master的通信。28注意事項n
Percona
Ser
ver5
.5
存在一個組提交導(dǎo)致半同步被打破的BUG。參考:
/percona-server/5.5/+bug/1254571n
MySQL
5.5存在一個SQL執(zhí)行時間隨rpl_semi_sync_master_timeout線性增長的BUG。參考:
/uid-20726500-id-5671668.htmln
偶發(fā)性的產(chǎn)生讀VIP的ARP緩存未及時更新的問題,應(yīng)用和數(shù)據(jù)庫在同一個網(wǎng)段時容易發(fā)生??蛇m當(dāng)減小ARP緩存失效時間。(和具體網(wǎng)絡(luò)環(huán)境有關(guān))29方案總結(jié)效果部署需求不足n
對無讀負(fù)載均衡需求的業(yè)務(wù),3節(jié)點存在資源浪費n
秒級故障切換(通常小于20秒)n
零數(shù)據(jù)丟失n
Linuxn
MySQL
主從延
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- GB/Z 45115-2024太陽能光熱發(fā)電站直接與間接式主動顯熱儲熱系統(tǒng)特性
- GB/T 10816-2024紫砂陶器
- TAT-PEG-Cy3-生命科學(xué)試劑-MCE-8780
- O-Methylcassythine-生命科學(xué)試劑-MCE-5707
- 1-2-Distearoyl-3-palmitoyl-rac-glycerol-1-2-Stearin-3-palmitin-生命科學(xué)試劑-MCE-3544
- 2025年度解除競業(yè)限制協(xié)議通知范本及注意事項
- 二零二五年度版果園承包合同:果業(yè)人才培養(yǎng)與引進(jìn)合作協(xié)議
- 二零二五年度2025年度自愿調(diào)解協(xié)議書-知識產(chǎn)權(quán)侵權(quán)糾紛調(diào)解協(xié)議書
- 2025年度共享汽車使用權(quán)授權(quán)管理協(xié)議
- 二零二五年度房屋租賃合同終止及換房新約
- 2024化工園區(qū)危險品運輸車輛停車場建設(shè)規(guī)范
- 工地試驗室質(zhì)量手冊
- 信息資源管理(馬費成-第三版)復(fù)習(xí)重點
- 郵輪外部市場營銷類型
- GB/T 42460-2023信息安全技術(shù)個人信息去標(biāo)識化效果評估指南
- 05G359-3 懸掛運輸設(shè)備軌道(適用于一般混凝土梁)
- 工程與倫理課程
- CKDMBD慢性腎臟病礦物質(zhì)及骨代謝異常
- 潮汕英歌舞課件
- 田字格模版內(nèi)容
- 第一章 公共政策分析的基本理論與框架
評論
0/150
提交評論