基于Pacemaker+MHA的MySQL高可用實(shí)踐

基于Pacemaker+MHA的MySQL高可用實(shí)踐n

曾經(jīng)的MySQL

HA方案n

如何防止腦裂和數(shù)據(jù)丟失n

實(shí)現(xiàn)方式的選擇n

基于Pacemaker實(shí)現(xiàn)MySQL

HAn

雙節(jié)點(diǎn)零數(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)故障時(shí)，集群腦裂，導(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

實(shí)現(xiàn)方式的選擇n

基于Pacemaker實(shí)現(xiàn)MySQL

HAn

雙節(jié)點(diǎn)零數(shù)據(jù)丟失HA方案5如何防止腦裂和數(shù)據(jù)丟失如何實(shí)現(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é)點(diǎn)隔離n

采用物理fence設(shè)備不通用，不易部署，可靠性也值得懷疑。n

引入中間層proxy，所有流量必須經(jīng)過proxy，由proxy隔離故障節(jié)點(diǎn)流量。增加復(fù)雜性，有性能損失，還要考慮proxy的高可用。n

每個(gè)節(jié)點(diǎn)上部署Agent，發(fā)現(xiàn)本節(jié)點(diǎn)已非合法Master，自行停止?；究尚小５荒芴幚鞳S

hang住的情況，可能存在時(shí)間差。并且Agent也可能出故障。8方法三：舊Master自行拒絕寫入n

設(shè)置超大的MySQL半同步復(fù)制降級為異步復(fù)制的超時(shí)時(shí)間(比如300天)，阻止脫離集群的舊Master寫入數(shù)據(jù)。9最終方案：組合拳n

3節(jié)點(diǎn)選主n

失去Quorum的分區(qū)自行釋放資源n

強(qiáng)制半同步3節(jié)點(diǎn)最多只能形成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é)點(diǎn)(0個(gè)或多個(gè))HA節(jié)點(diǎn)(3個(gè))11n

曾經(jīng)的MySQL

HA方案n

如何防止腦裂和數(shù)據(jù)丟失n

實(shí)現(xiàn)方式的選擇n

基于Pacemaker實(shí)現(xiàn)MySQL

HAn

雙節(jié)點(diǎn)零數(shù)據(jù)丟失HA方案12實(shí)現(xiàn)方式1：

Zookeeper

+Monitor

+Agent

+

MHAn

Zookeeper存儲集群狀態(tài)和選主n

Monitor集群控制n

Agent做健康監(jiān)視和命令執(zhí)行n

MHA做實(shí)際的failover(包含日志補(bǔ)償)優(yōu)點(diǎn)：n

靈活可控缺點(diǎn)：n

缺少完整的集群管理，一切都要自己實(shí)現(xiàn)。13實(shí)現(xiàn)方式2：

Pacemaker

+

定制Agent

+MHAn

Pacemaker

+

Corosync統(tǒng)一進(jìn)行資源管理n

資源Agent監(jiān)視各類資源n

MHA做實(shí)際的failover(包含日志補(bǔ)償)優(yōu)點(diǎn)：n

通用成熟的集群套件n

各個(gè)資源互相獨(dú)立并可通過配置靈活組合缺點(diǎ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

實(shí)現(xiàn)方式的選擇n

基于Pacemaker實(shí)現(xiàn)MySQL

HAn

雙節(jié)點(diǎn)零數(shù)據(jù)丟失HA方案16Pacemaker簡介(1/2)Pacemaker+

Corosync是目前Linux下的首選集群套件（RHEL7里已經(jīng)取代了RHCS），已被包含在主流Linux發(fā)行版中。功能特性n節(jié)點(diǎn)管理增加，刪除，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開源項(xiàng)目自帶的mysql和ldirectord

RA。實(shí)現(xiàn)架構(gòu)n

新開發(fā)MySQL和LVS的Resource

Agent進(jìn)行資源監(jiān)控n

每個(gè)節(jié)點(diǎn)部署MHA

node做實(shí)際的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é)點(diǎn)故障人工發(fā)起在線切換更新集群CIB由于是強(qiáng)制半同步并有日志補(bǔ)償，所以提升任何一個(gè)Slave節(jié)點(diǎn)作為新Master都不會丟失數(shù)據(jù)！Pengine計(jì)算集群最佳狀態(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個(gè)HA節(jié)點(diǎn)上分配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

實(shí)施故障切換前，檢查本分區(qū)是否包含2個(gè)以上的HA節(jié)點(diǎn)，如否放棄切換。分區(qū)1分區(qū)2Master阻止其升級為MasterSlaveSlaveSlaveSlaveHA節(jié)點(diǎn)(3個(gè))只讀節(jié)點(diǎn)(2個(gè))21故障節(jié)點(diǎn)隔離(1/3)n

記錄包含切換次數(shù)和master節(jié)點(diǎn)名的master信息，阻止master信息不一致的節(jié)點(diǎn)(比如舊Master)上線。master信息源

存放位置內(nèi)容集群CIB本地文件MySQL//crm_config/mysql_replication/master_info

${切換次數(shù)}_${master節(jié)點(diǎn)名}/opt/mysql_ha/etc/master_infoshow

slave

status->Master_Host${切換次數(shù)}_${master節(jié)點(diǎn)名}主節(jié)點(diǎn):空從節(jié)點(diǎn):${master節(jié)點(diǎn)名}22故障節(jié)點(diǎn)隔離(2/3)n

阻止MySQL運(yùn)行中物理機(jī)或OS發(fā)生crash的節(jié)點(diǎn)上線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é)點(diǎn)可能和其它節(jié)點(diǎn)的數(shù)據(jù)不一致，必須阻止這樣的節(jié)點(diǎn)自動上線。23故障節(jié)點(diǎn)隔離(3/3)n

設(shè)置合理的遷移閾值，限制故障資源在原節(jié)點(diǎn)上重試的次數(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é)點(diǎn)網(wǎng)絡(luò)切斷5.

節(jié)點(diǎn)網(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.

測試下一個(gè)故障9.

循環(huán)測試下一輪（24小時(shí)不間斷）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é)點(diǎn)也設(shè)置了rpl_semi_sync_master_enabled=1，導(dǎo)致MHA做日志補(bǔ)償時(shí)hang住。解決辦法：調(diào)用MHA前臨時(shí)設(shè)置rpl_semi_sync_master_enabled=0，補(bǔ)償后再恢復(fù)。n

MHA中也有對舊Master的生死判斷，由于時(shí)間差以及判斷邏輯的差異，判斷結(jié)果和Pacemaker可能不一致，引發(fā)其它故障。解決辦法:

調(diào)用MHA前通過防火墻臨時(shí)阻斷MHA切換腳本到舊Master的通信。28注意事項(xiàng)n

Percona

Ser

ver5

.5

存在一個(gè)組提交導(dǎo)致半同步被打破的BUG。參考：

/percona-server/5.5/+bug/1254571n

MySQL

5.5存在一個(gè)SQL執(zhí)行時(shí)間隨rpl_semi_sync_master_timeout線性增長的BUG。參考：

/uid-20726500-id-5671668.htmln

偶發(fā)性的產(chǎn)生讀VIP的ARP緩存未及時(shí)更新的問題，應(yīng)用和數(shù)據(jù)庫在同一個(gè)網(wǎng)段時(shí)容易發(fā)生?？蛇m當(dāng)減小ARP緩存失效時(shí)間。（和具體網(wǎng)絡(luò)環(huán)境有關(guān)）29方案總結(jié)效果部署需求不足n

對無讀負(fù)載均衡需求的業(yè)務(wù)，3節(jié)點(diǎn)存在資源浪費(fèi)n

秒級故障切換(通常小于20秒)n

零數(shù)據(jù)丟失n

Linuxn

MySQL

主從延