金融級MySQL高可用方案選型

1、 金融級MySQL高可用方案選型 背景市面上關(guān)于MySQL高可用方案五花八門：Keepalived，3M，MHA，甚至通過負(fù)載均衡，proxy中間件等等方案來實(shí)現(xiàn)。那么怎么來對這些選型做評判呢？本文將圍繞下面的主線邏輯進(jìn)行探討：高可用的考量：為什么選型這種高可用方案，需要有什么標(biāo)準(zhǔn)來考量？高可用覆蓋的故障：高可用要處理哪些層級的故障，不同故障場景下，考量的適用度是多少？高可用的選型：有了故障場景，有了考量標(biāo)準(zhǔn)后，探討如何選型？一. 高可用的考量在討論高可用考量之前我們來看一個(gè)簡單的高可用架構(gòu)模型（下圖）；這個(gè)模型很簡單，有一個(gè)HA的工具去檢測主從狀態(tài)，發(fā)現(xiàn)主實(shí)例異常后，就發(fā)生故障切換，切換前可

2、能還需要做一些提升（Promote）的操作，比如數(shù)據(jù)補(bǔ)全，最后才綁定服務(wù)IP（ServiceIP），對外提供流量。1.png上面的模型是一個(gè)比較經(jīng)典的高可用模型，用過高可用的同學(xué)應(yīng)該能對號入座，沒用過的同學(xué)會(huì)對高可用有一個(gè)基本的印象。有了對高可用功能的簡單刻畫，我們回到本章正題，來探討高可用的考量；熟悉Oracle的同學(xué)，應(yīng)該都知道Oracle的Data Guard。DG是Oracle推出的一種針對Oracle數(shù)據(jù)庫的高可用性數(shù)據(jù)庫方案。它有三種工作模式： 最大性能，最大可用，最大保護(hù)。所以針對MySQL的高可用性考量，那么我們同樣定義了類似的標(biāo)準(zhǔn)：數(shù)據(jù)一致性。通過不同的高可用保障方式（異步同

3、步復(fù)制）實(shí)現(xiàn)主庫發(fā)生切換時(shí)，數(shù)據(jù)零丟失。 2.業(yè)務(wù)連續(xù)性。業(yè)務(wù)連續(xù)性是指數(shù)據(jù)庫的消費(fèi)者(業(yè)務(wù)),是否可以一直訪問和使用數(shù)據(jù)庫。在發(fā)生主備切換時(shí),數(shù)據(jù)庫的業(yè)務(wù)連續(xù)性會(huì)受到多長時(shí)間的影響。數(shù)據(jù)庫性能。由于主備上至少存有兩份數(shù)據(jù),與只有一份數(shù)據(jù)相比,主數(shù)據(jù)庫承擔(dān)業(yè)務(wù)壓力的能力可能會(huì)受到影響，需要做好性能平衡。到這里，似乎我們得到了一套高可用的考量標(biāo)準(zhǔn)，我們的問題馬上又接踵而至。1.1 一致性vs性能一致性優(yōu)先，全同步，數(shù)據(jù)slave提交后，master再提交性能優(yōu)先，異步，master直接提交，slave異步復(fù)制問題1：如何平衡一致性和性能？1.2 一致性vs連續(xù)性數(shù)據(jù)一致性優(yōu)先時(shí),將盡可能補(bǔ)償數(shù)據(jù)

4、,補(bǔ)償數(shù)據(jù)階段花費(fèi)的時(shí)間將較長,在補(bǔ)償數(shù)據(jù)期間業(yè)務(wù)將不能訪問;業(yè)務(wù)連續(xù)性優(yōu)先時(shí),將在規(guī)定時(shí)間t內(nèi)補(bǔ)償數(shù)據(jù),達(dá)到規(guī)定時(shí)間t后,放棄未補(bǔ)償?shù)臄?shù)據(jù),保證業(yè)務(wù)最多只中斷t時(shí)間問題2：如何平衡一致性和連續(xù)性？上面的兩個(gè)問題我們暫且賣個(gè)關(guān)子，到高可用選型的章節(jié)里在給大家展開探討！二. 高可用覆蓋的故障上一章我們談?wù)摿烁呖捎玫目剂浚@一節(jié)我們要探討高可用要處理哪些層級的故障，不同故障場景下，考量的適用度是多少？故障檢測的目的是保證某一節(jié)點(diǎn)故障時(shí), HA能及時(shí)獲得通知, 并開啟修復(fù)或切換任務(wù)。節(jié)點(diǎn)故障包括由硬件故障, 網(wǎng)絡(luò)故障，操作系統(tǒng)故障, 被監(jiān)控軟件故障, 或監(jiān)控軟件的故障引起的節(jié)點(diǎn)狀態(tài)異?；蚴ロ憫?yīng)。2

5、.png2.1 硬件故障硬件故障可能是可恢復(fù)的, 也可能不可恢復(fù). 由于無法全面且準(zhǔn)確地預(yù)測硬件故障的發(fā)生時(shí)間/發(fā)生種類/產(chǎn)生的影響等, 一般對硬件故障的檢測方法如下：對可預(yù)測的硬件故障進(jìn)行故障檢測/預(yù)防性檢測檢測由高層應(yīng)用拋出的錯(cuò)誤什么意思呢，無法預(yù)測？那要我們高可用軟件做什么？別急！大家考慮一下，如果我們要檢測一個(gè)硬件故障，大致的思路其實(shí)是有的，無非就是去檢測硬件的錯(cuò)誤碼，回頭想想，光磁盤的供應(yīng)商何其多，如果要把兼容性做齊，這個(gè)工程量可想而知；所以我們的結(jié)論是預(yù)防大于治療。比如電源故障我們要上備用電池（BBU），磁盤做Raid，網(wǎng)卡做Bond等等一系列的運(yùn)維規(guī)范。那么無非防范的其他的硬件故

6、障，我們依賴于高層應(yīng)用的拋錯(cuò)來檢測，比如系統(tǒng)報(bào)錯(cuò)disk read only，MySQL abort server等等。PS：高可用是一個(gè)運(yùn)維體系，除了高可用軟件，還需要配套運(yùn)維規(guī)范；這也是為啥DBA年限越久價(jià)值越大的一種體現(xiàn)吧！2.2 網(wǎng)絡(luò)故障網(wǎng)絡(luò)故障也可以細(xì)分成以下幾類。2.2.1 網(wǎng)絡(luò)不可用網(wǎng)絡(luò)不可用指較長時(shí)間網(wǎng)絡(luò)通路不可用, 可通過節(jié)點(diǎn)間心跳來檢測.2.2.2 網(wǎng)絡(luò)閃斷網(wǎng)絡(luò)閃斷指較短時(shí)間內(nèi)網(wǎng)絡(luò)在可用和不可用狀態(tài)間震蕩. 可將心跳檢測的超時(shí)時(shí)間設(shè)為能容忍的網(wǎng)絡(luò)閃斷的最長時(shí)間 t,即容忍最長t時(shí)間的網(wǎng)絡(luò)中斷, 超時(shí)則認(rèn)為網(wǎng)絡(luò)中斷。2.2.3 網(wǎng)絡(luò)穩(wěn)定性和延遲網(wǎng)絡(luò)穩(wěn)定性和延遲可以由以下特征量

7、進(jìn)行描述,節(jié)點(diǎn)間的網(wǎng)絡(luò)通訊協(xié)議需能正常工作于由以下特征量描述的某網(wǎng)絡(luò)上網(wǎng)絡(luò)包丟失率網(wǎng)絡(luò)包損壞率網(wǎng)絡(luò)包亂序率網(wǎng)絡(luò)包重復(fù)率網(wǎng)絡(luò)包延時(shí)時(shí)間大部分的高可用軟件會(huì)覆蓋前兩類場景，但是在不同的用戶環(huán)境下，網(wǎng)絡(luò)的質(zhì)量其實(shí)是參差不齊的。如何在差網(wǎng)絡(luò)條件下，高可用軟件仍能夠正常工作，不會(huì)有過多的誤判？可行的一種實(shí)現(xiàn)方式是：在差網(wǎng)絡(luò)條件下，高可用的檢測敏感度要按比例降低。2.3 操作系統(tǒng)故障類似于硬件故障, 無法全面且準(zhǔn)確預(yù)測其發(fā)生時(shí)間/發(fā)生種類/產(chǎn)生的影響. 類似于硬件故障的檢測方法。對可預(yù)測的操作系統(tǒng)故障進(jìn)行故障檢測/預(yù)防性檢測對資源的使用, 如磁盤/內(nèi)存等, 進(jìn)行監(jiān)控和閾值告警檢測由高層應(yīng)用拋出的錯(cuò)誤類似于

8、硬件故障的邏輯，對于部分系統(tǒng)故障我們要做防范，比如磁盤禁用cache，MySQL的 O_DIRECT 方式可以跳過pagecache寫數(shù)據(jù)，MySQL的參數(shù)innodb_flush_log_at_trx_commit=1，sync_binlog =1等等。除了預(yù)防，我們還要接外援的監(jiān)控，因?yàn)樽屢粋€(gè)高可用軟件告訴你，磁盤快要滿了，似乎不太合適，這些是監(jiān)控告警擅長的事情。2.4 被監(jiān)控軟件的故障被監(jiān)控軟件的故障檢測,不能簡單檢測其進(jìn)程是否存在,還需要根據(jù)其特點(diǎn)進(jìn)行細(xì)致的檢測。針對MySQL, 我們用一張思維導(dǎo)圖來展示如下圖：3.pngMySQL的故障不但要處理MySQL的健康問題，復(fù)制是MySQL

9、的冗余手段，對于復(fù)制的檢測修復(fù)，同樣是需要一個(gè)高可用軟件去容錯(cuò)的。2.5 監(jiān)控軟件故障監(jiān)控軟件的故障常見的有:意外退出失去響應(yīng)由于資源被其它應(yīng)用搶占, 發(fā)生崩潰由于資源被其它應(yīng)用搶占, 響應(yīng)速度變慢, 引發(fā)時(shí)序錯(cuò)誤長期運(yùn)行時(shí), 資源被緩慢占用得不到釋放一些時(shí)序服務(wù), 如日志回收/分布式鎖/等, 在監(jiān)控軟件發(fā)生故障后無法回收現(xiàn)場,產(chǎn)生后效性對監(jiān)控軟件來說,自身的故障也是一類故障。通常由于監(jiān)控軟件相比于被監(jiān)控軟件其規(guī)模較小,且其測試著重于可用性測試,故其發(fā)生故障的概率較低,不易受重視。通用的處理手法是使用守護(hù)進(jìn)程,在監(jiān)控軟件意外退出時(shí)進(jìn)行守護(hù)。但遠(yuǎn)遠(yuǎn)不夠。問題3:監(jiān)控軟件自身的可用性如何保障？2.

10、6 腦裂上面我們討論的故障都是單點(diǎn)的故障，如果回到高可用集群自身，還有一類故障是不容忽視的，那就是腦裂！HA到Master之間的連接不通，認(rèn)為主庫Crash。選擇將備庫提升為主庫。但實(shí)際上，只是HA到Master間的網(wǎng)絡(luò)有問題，原主庫是好的（沒有被降級為備庫，或者是關(guān)閉），仍舊能夠?qū)ν馓峁┓?wù)。新的主庫也可以對外提供服務(wù)。兩個(gè)主庫，產(chǎn)生雙寫問題，我們說集群腦裂了。4.png問題4:如何解決腦裂問題？2.7 小結(jié)這一章我們探討了不同層次故障場景，需要通過不同的手法來避免可用性問題，比如增加運(yùn)維規(guī)范，對接外援監(jiān)控，同時(shí)對高可用軟件需要做網(wǎng)絡(luò)環(huán)境的適配，做細(xì)致的故障場景的拆分和處理等。同時(shí)我們遺留了

11、兩個(gè)問題：問題3:監(jiān)控軟件自身的可用性如何保障？問題4:如何解決腦裂問題？三. 高可用的選型有故障場景，有考量標(biāo)準(zhǔn)后，這一章我們來探討如何選型。選型的討論我們圍繞著遺留四個(gè)問題進(jìn)行展開一致性 & 性能問題1:如何平衡一致性和性能？一致性 & 連續(xù)性問題2:如何平衡一致性和連續(xù)性？集群可用性問題3:監(jiān)控軟件自身的可用性如何保障？問題4:如何解決腦裂問題？3.1 一致性 & 性能一致性的需求是數(shù)據(jù)零丟失（全同步復(fù)制）；性能的需求是性能最大化（異步復(fù)制）；這從概念上來講是兩個(gè)極端，中間要選個(gè)平衡的話，半同步方案就可能脫穎而出。我們在工程實(shí)現(xiàn)中做了更多，我們不但選型了半同步的方案，我們還會(huì)探討異步復(fù)制

12、的方案！3.1.1 選型一：半同步半同步的簡要實(shí)現(xiàn)見下圖。事務(wù)提交的時(shí)候，發(fā)起兩個(gè)寫日志操作，一個(gè)是將日志寫到本地磁盤的操作，另一個(gè)是將日志同步到備庫并且確保落盤的操作；主庫此時(shí)等待兩個(gè)操作全部成功返回之后，才返回給應(yīng)用方，事務(wù)提交成功；5.png由于事務(wù)提交操作返回給應(yīng)用時(shí)，事務(wù)產(chǎn)生的日志在主備兩個(gè)數(shù)據(jù)庫上都已經(jīng)存在了。因此，此時(shí)主庫Crash的話，備庫提供服務(wù)，其數(shù)據(jù)與主庫是一致的，沒有任何事務(wù)的數(shù)據(jù)丟失問題。主備數(shù)據(jù)強(qiáng)一致實(shí)現(xiàn)。當(dāng)然這個(gè)方案存在一定的限制：必須是MySQL5.7的半同步。5.6的半同步，圖中第五步engine commit會(huì)先于第四步的ACK，一旦引擎層提交了，其他事務(wù)就

13、能看到數(shù)據(jù)，這就會(huì)帶來可見性一致性的問題；半同步會(huì)降級。半同步等ACK超時(shí)會(huì)自動(dòng)降級，這樣一致性就無法保障，或者將超時(shí)時(shí)間調(diào)整到無限大，這樣的會(huì)走向另一個(gè)極端，Master事務(wù)會(huì)發(fā)生hang，業(yè)務(wù)連續(xù)性會(huì)丟失；因?yàn)榇嬖谙拗?，如何讓半同步方案更優(yōu)雅一些，不走兩個(gè)極端？場景1：升降級檢測。半同步rpl_semi_sync_master_timeout超時(shí)降級時(shí)，那么HA應(yīng)該檢測到半同步降級，實(shí)時(shí)通知DBA丟失一致性保障半同步自動(dòng)回來時(shí)，那么HA應(yīng)該檢測到半同步升級，并實(shí)時(shí)通知DBA獲得一致性保障場景2:調(diào)度半同步啟停。如果slave全掛了的場景，這時(shí)候mater其實(shí)會(huì)被hang住，HA在這種場景

14、下應(yīng)該停止master上的半同步場景3:調(diào)度slave count數(shù)。rpl_semi_sync_master_wait_slave_count控制主庫接受多少個(gè)slave寫事務(wù)成功反饋。slave count數(shù)代表了高可用完整副本的個(gè)數(shù)，可以調(diào)節(jié)數(shù)據(jù)庫的一致性和性能的平衡。所以高可用手段如果選型的半同步，高可用必須接管HA的調(diào)度，包括但不限于：調(diào)度半同步起停檢測半同步狀態(tài)調(diào)度slave count數(shù)3.1.2 選型二：binlog落共享磁盤在半同步的方案中，我們依賴半同步binlog在slave上先落盤，事務(wù)在提交的方式來保障一致性；那么異步復(fù)制如何來解決一致性問題呢？我們引入了一個(gè)外部技術(shù)

15、，引入外部技術(shù)會(huì)降低整集群的可用性，但是它帶個(gè)了我們無法拒絕的特性，數(shù)據(jù)一致性！通過binlog落共享存儲(chǔ)盤，切換時(shí)爭搶主機(jī)端binlog盤來補(bǔ)償數(shù)據(jù)，保障數(shù)據(jù)不丟失，如下圖整個(gè)對共享存儲(chǔ)磁盤的控制，是通過國際標(biāo)準(zhǔn)的Scsi PR協(xié)議完成磁盤注冊，預(yù)留，搶占；部署時(shí)，master和slave對磁盤LUN1和磁盤LUN2都進(jìn)行了注冊（類似共享鎖）運(yùn)行時(shí)，master對磁盤LUN1進(jìn)行預(yù)留，slave對磁盤LUN2進(jìn)行預(yù)留（類似排他鎖）切換時(shí)，salve對mater的磁盤LUN1進(jìn)行搶占，獲得LUN1的讀寫權(quán)限，并把差異的binlog對slave進(jìn)行補(bǔ)全通過binlog共享存儲(chǔ)的方式，因?yàn)橹恍枰?/p>

16、步復(fù)制，也就很好的平衡了數(shù)據(jù)一致性和性能的問題！3.2 一致性 & 連續(xù)性一致性優(yōu)先：盡一切手段補(bǔ)全連續(xù)性優(yōu)先：規(guī)定時(shí)間內(nèi)必須切換到底應(yīng)該聽誰的？我們提出了SLA的概念。SLA服務(wù)等級協(xié)議（簡稱：SLA，全稱：service level agreement），是業(yè)務(wù)根據(jù)需求與SLA組件簽訂的保障數(shù)據(jù)一致性或服務(wù)連續(xù)性的等級協(xié)議；3.2.1保障數(shù)據(jù)一致性的RPO協(xié)議6.pngRPO協(xié)議規(guī)定了允許丟失的數(shù)據(jù)量（默認(rèn)是零丟失）。用戶可自行配置。數(shù)據(jù)一致性級別分為兩大類：P級別，能正常保障RPO協(xié)議；PE級別，不能保證RPO協(xié)議（需要人工干預(yù)）。數(shù)據(jù)一致性級別每大類下有若干小級別，是根據(jù)主從延時(shí)的粒度

17、進(jìn)行的細(xì)分。3.2.2保障數(shù)據(jù)連續(xù)性的RTO協(xié)議7.pngRTO協(xié)議規(guī)定了允許服務(wù)停止的時(shí)間（默認(rèn)是10分鐘）。用戶可自行配置。數(shù)據(jù)連續(xù)性級別分為兩大類：T級別，能正常保障RTO協(xié)議；TE級別，不能保證RTO協(xié)議（需要人工干預(yù)）。數(shù)據(jù)連續(xù)性級別每大類下有若干小級別，是根據(jù)數(shù)據(jù)丟失的粒度進(jìn)行的細(xì)分。定義了RPO和RTO協(xié)議后，HA在運(yùn)行時(shí)，按照綁定的協(xié)議來進(jìn)行切換即可。3.3 集群可用性HA自身可用性？腦裂？我們可以通過引入一致性選舉算法，比如Paxos，Raft協(xié)議，來解決上面提到的兩個(gè)問題；HA集群化部署，各節(jié)點(diǎn)之間角色對稱；一致性選舉算法選舉出leader，由leader來做HA的所有決策

18、（如下圖，左邊是單點(diǎn)部署，右邊集群部署），由此我們解決HA自身單點(diǎn)的問題。當(dāng)右邊HA1從網(wǎng)絡(luò)中割裂出去的時(shí)候，一致性選舉算法需要超過眾數(shù)節(jié)點(diǎn)才能選舉，（HA1將失去眾數(shù)節(jié)點(diǎn)，HA2和HA3將構(gòu)成新集群），由此我們解決HA集群的腦裂的問題。8.png我們對這個(gè)架構(gòu)又進(jìn)行了升級：如下圖9.png左邊的架構(gòu)圖一：HA節(jié)點(diǎn)即是agent端，也可能是mgr端（如果被選舉為leader）如果有上百個(gè)節(jié)點(diǎn)的時(shí)候，這個(gè)集群可能存在一個(gè)問題，比如集群要重新做一次選舉，那么上百個(gè)節(jié)點(diǎn)間需要做通信，所以全民選舉的效率會(huì)很低；適合小規(guī)模的高可用集群。右邊的架構(gòu)圖二：HA天然的分成agent端和mgr端。如果有上百個(gè)節(jié)點(diǎn)的時(shí)候，只會(huì)有上百個(gè)agent節(jié)點(diǎn)，mgr端可以控制在一個(gè)小規(guī)模的集群范圍內(nèi)，保障選舉的效率，適合大規(guī)模的高可用集群。3.4 小結(jié)如何平衡