寫在前面
愛奇藝每天都為數(shù)以億計(jì)的用戶提供7*24小時(shí)不間斷的視頻服務(wù)。通過(guò)愛奇藝的平臺(tái)，用戶可以方便的獲取海量、優(yōu)質(zhì)、高清的視頻資源。但如果服務(wù)平臺(tái)出現(xiàn)故障，會(huì)有大量的用戶將無(wú)法正常播放視頻，因此我們的應(yīng)用服務(wù)以及數(shù)據(jù)庫(kù)服務(wù)都必須具備高可用架構(gòu)。
愛奇藝技術(shù)產(chǎn)品團(tuán)隊(duì)對(duì)各類應(yīng)用劃分了不同的重要等級(jí)，對(duì)不同重要等級(jí)的應(yīng)用使用數(shù)據(jù)庫(kù)服務(wù)提供了不同的 SLA 保障。比如 S 級(jí)應(yīng)用 RTO 控制在分鐘級(jí)別的保障；對(duì) A 級(jí)應(yīng)用 RTO 在 10 分鐘級(jí)別的保障等。本文將主要介紹我們的 MySQL 高可用實(shí)現(xiàn)方案。
自研MySQL HA系統(tǒng)
1. 基于MHA二次開發(fā)
MHA是目前比較成熟及流行的MySQL高可用解決方案，很多互聯(lián)網(wǎng)公司正是直接使用或者基于MHA的架構(gòu)進(jìn)行改造實(shí)現(xiàn)MySQL的高可用。MHA能在30秒內(nèi)對(duì)故障進(jìn)行轉(zhuǎn)移，并最大程度的保障數(shù)據(jù)的一致性。MHA由兩個(gè)模塊組成：Manager和 Node。
Manager部署在獨(dú)立的機(jī)器上，負(fù)責(zé)檢查MySQL復(fù)制狀態(tài)、主庫(kù)狀態(tài)以及執(zhí)行切換操作。Node運(yùn)行在每臺(tái)MySQL機(jī)器上，主要負(fù)責(zé)保存和復(fù)制master binlog、識(shí)別主庫(kù)宕機(jī)時(shí)各Slave差異的中繼日志并將差異的事務(wù)應(yīng)用到其他的Slave，同時(shí)還負(fù)責(zé)清除Slave上的relay_log。
它的部署架構(gòu)如下圖所示：
圖1：MHA架構(gòu)
MHA雖然已經(jīng)比較成熟，但也存在一些的缺點(diǎn)：
-
使用配置文件管理主備關(guān)系、不能重復(fù)切換
-
實(shí)例增減需要重啟Manager
-
Manager是單點(diǎn)，雖然有standby的節(jié)點(diǎn)，但不能自動(dòng)切換
另外我們的MySQL部署環(huán)境復(fù)雜，存在跨DC跨地域的部署，新主的選舉需要更多的規(guī)則。并且集群數(shù)量較為龐大，如果直接采用MHA做高可靠用，會(huì)大大增加管理成本。因此我們自研了一套MySQL的高可用方案。
2. MySQL HA架構(gòu)簡(jiǎn)介
愛奇藝自研MysQL HA系統(tǒng)由HA Master和HA Agent兩部分組成。三個(gè)HA Master組成一個(gè)最小集群?jiǎn)卧@個(gè)最小集群?jiǎn)卧獙?duì)應(yīng)MHA的Manager，通過(guò)raft協(xié)議實(shí)現(xiàn)高可用，解決Manager單點(diǎn)和不能重復(fù)切換的問(wèn)題。HA Agent功能和MHA Node功能類似，負(fù)責(zé)責(zé)故障檢測(cè)、解析和傳輸 binlog、清理 relay log 以 及負(fù)責(zé) MGR 的高可用。
圖2：HA系統(tǒng)架構(gòu)
(1) HA Master
HA Master使用了raft的JAVA實(shí)現(xiàn)—copycat框架來(lái)進(jìn)行Leader選舉和Session監(jiān)聽，HA Master多機(jī)房部署。HA Master有三個(gè)重要模塊：狀態(tài)機(jī)、心跳模塊和切換模塊，狀態(tài)機(jī)保存當(dāng)前raft leader的地址，心跳模塊和Agent保持10秒1次的心跳檢查，收到Agent心跳后會(huì)更新心跳時(shí)間戳和實(shí)例狀態(tài)。每次Leader重選，新的Leader會(huì)更新狀態(tài)機(jī)的leader地址。Agent注冊(cè)到各個(gè)HA Master的狀態(tài)機(jī)內(nèi)，如果狀態(tài)機(jī)里的Leader地址發(fā)生了變更，則發(fā)布變更數(shù)據(jù)給每個(gè)注冊(cè)的Agent，Agent再向新的Leader發(fā)送rpc心跳。
圖3：HA架構(gòu)
切換模塊則負(fù)責(zé)具體的故障切換，通過(guò)定期輪訓(xùn)badinstance集合，對(duì)符合條件的實(shí)例進(jìn)行切換。支持自動(dòng)和手動(dòng)兩種切換方式。對(duì)于自動(dòng)切換，需要在CMDB里配置好切換策略，可選同DC切換、跨DC切換還是跨地域切換。
切換流程如圖所示：
圖4：故障切換流程
除了對(duì)主庫(kù)支持故障切換外，也具備對(duì)從庫(kù)故障切換的能力。在從庫(kù)故障宕機(jī)時(shí)，通過(guò)檢測(cè)故障，再操作域名的方式實(shí)現(xiàn)Slave的高可用。
(2) HA Agent
Agent負(fù)責(zé)監(jiān)控CMDB里狀態(tài)為online的實(shí)例，通過(guò)檢查mysqld進(jìn)程是否存在等規(guī)則判斷實(shí)例是否存活，如果判斷實(shí)例宕機(jī)則向HA Master發(fā)送包含badinstance的RPC心跳。如果是機(jī)器宕機(jī)，HA Master會(huì)收到Agent的超時(shí)事件，并對(duì)心跳超時(shí)的Agent所在服務(wù)器上的實(shí)例進(jìn)行切換。為了盡量避免網(wǎng)絡(luò)抖動(dòng)造成誤切，我們把Agent超時(shí)時(shí)長(zhǎng)設(shè)置為1分鐘，1分鐘內(nèi)的閃斷或者抖動(dòng)不做切換。
Agent還負(fù)責(zé)對(duì)MGR的Primary節(jié)點(diǎn)進(jìn)行監(jiān)控和域名切換。MGR在主節(jié)點(diǎn)發(fā)生切換后，客戶端需要去捕獲這個(gè)切換信息，再把請(qǐng)求重新指向新的主節(jié)點(diǎn)，這對(duì)于業(yè)務(wù)來(lái)說(shuō)不友好。因此我們給Agent增加一個(gè)功能，當(dāng)發(fā)現(xiàn)主節(jié)點(diǎn)發(fā)生過(guò)切換后，就把源主節(jié)點(diǎn)上的域名重綁到新的主節(jié)點(diǎn)上，從而實(shí)現(xiàn)MGR故障切換對(duì)業(yè)務(wù)的透明。
圖5：MGR高可用方案
3. HA的選主規(guī)則
HA需要一套復(fù)雜的選主規(guī)則，用以適配我們復(fù)雜的部署環(huán)境，選主規(guī)則如下：
-
排除在bad slaves里的slave
-
選擇所有l(wèi)atest slaves優(yōu)先級(jí)最高的candidate master
-
如果從庫(kù)沒(méi)有設(shè)置優(yōu)先級(jí)，選出所有非bad slaves的slave
-
根據(jù)切換策略，依次選擇同DC->同region->跨region的slave。
-
對(duì)滿足條件的從庫(kù)，排除從庫(kù)所在機(jī)器Master個(gè)數(shù)和Slave個(gè)數(shù)太多的salve，在剩下的slave中選擇機(jī)器剩余磁盤空間最大的slave。
通過(guò)以上規(guī)則，選出一個(gè)最優(yōu)的主進(jìn)行切換。如果沒(méi)有滿足條件的slave，則會(huì)通過(guò)電話告警的方式通知DBA進(jìn)行人工干預(yù)。
4. 補(bǔ)全diff binlog
在Master切換過(guò)程中，會(huì)存在3種類型的diff binlog：
-
從庫(kù)io thread接收到的relay log不完整，不是一個(gè)完整的事務(wù)或完整的binlog event。
-
lastest slave與其他slave存在的diff relay log。
-
如果dead master機(jī)器還能訪問(wèn), 則還包括dead master未發(fā)送的diff binlog。
diff binlog的恢復(fù)順序如圖所示：
圖6：數(shù)據(jù)恢復(fù)步驟
如果是使用gtid復(fù)制，需要生成3種diff binlog文件，然后順序Apply diff binlog文件，恢復(fù)從庫(kù)。非gtid復(fù)制，先change master到lastest slave，先讓slave從lastest slave恢復(fù)數(shù)據(jù)，然后再apply dead master未發(fā)送的diff binlog 文件，完成binlog補(bǔ)齊。
5. 數(shù)據(jù)一致性的重要性
如果采用半同步復(fù)制，且主庫(kù)宕機(jī)瞬間沒(méi)有發(fā)生網(wǎng)絡(luò)超時(shí)，則HA能保證切換以后數(shù)據(jù)的一致性。但如果主庫(kù)宕機(jī)瞬間，網(wǎng)絡(luò)存在超時(shí)會(huì)導(dǎo)致半同步復(fù)制退化為異步復(fù)制，此時(shí)發(fā)生切換就可能丟失數(shù)據(jù)。這種情況需要業(yè)務(wù)端具備補(bǔ)償機(jī)制，對(duì)數(shù)據(jù)進(jìn)行補(bǔ)齊。但如果是MGR，不會(huì)存在數(shù)據(jù)丟失的問(wèn)題。
結(jié)束語(yǔ)
我們結(jié)合愛奇藝多種內(nèi)部監(jiān)控系統(tǒng)、資產(chǎn)管理系統(tǒng)、CMDB、鏈路追蹤以及混沌工程平臺(tái)開發(fā)一個(gè)面向業(yè)務(wù)的應(yīng)用運(yùn)維平臺(tái)，提供一站式服務(wù)撥測(cè)、巡檢、資源使用分析、調(diào)用鏈路追蹤以及故障演練等功能。通過(guò)混沌工程平臺(tái)提供的故障注入能力，對(duì)S級(jí)業(yè)務(wù)的數(shù)據(jù)庫(kù)進(jìn)行攻防演練。經(jīng)過(guò)不斷的迭代優(yōu)化，數(shù)據(jù)庫(kù)的攻防演練會(huì)成為常態(tài)，通過(guò)不斷的演練提升應(yīng)用的可用性和安全性，真正做到有備無(wú)患。
技術(shù)原創(chuàng)及架構(gòu)實(shí)踐文章，歡迎通過(guò)公眾號(hào)菜單「聯(lián)系我們」進(jìn)行投稿。
高可用架構(gòu)
改變互聯(lián)網(wǎng)的構(gòu)建方式
