1、網(wǎng)易考拉基于MGR的高可用架構(gòu)技術(shù)創(chuàng)新 變革未來深入MySQL Group Replication01基于MGR 多副本高可用集群架構(gòu)設(shè)計(jì)基于MGR Muti-Primary水平擴(kuò)展方案基于MGR的跨機(jī)房高可用實(shí)踐020304MySQL 數(shù)據(jù)庫的高可用發(fā)展歷程Share NothingShare StorageMaster-Slave RplMMMMHALoss-Less RplBinlog DWGaleraMGRDRBDAuroraPolarDBSANMySQL Group Replication多副本數(shù)據(jù)庫集群面臨的挑戰(zhàn)全局事務(wù)的排序成員節(jié)點(diǎn)的管理沖突檢測機(jī)制節(jié)點(diǎn)處理能力協(xié)同MySQL 5

2、.7.17 ReleaseA new MySQL PluginMuti-Duplicate ClusterData ConsistencySingle/Muti-Primary modeMenciousGroup ViewWrite SetFlow ControlMGR 事務(wù)提交處理流程ClientServerngOther ServerOther ServerUPDATEOKNativeProcessiCOMMITCertificationPaxos CertificationCertificationCommitrollbackCommitrollbackCommitrollbackOKO

3、KOKNot OKNot OKNot OKClient Execute DMLNative ProcessingBefore Commit HookGTID AllocatedCreate WriteSetFlow ControlPaxos InstanceCertificationWrite Relay LogParallel Replay全局事務(wù)的排序PAAprepareacceptBasic PaxosPAAprepareacceptPAacceptRaft/Multi PaxosAAA AAA0，3，6 3*nA1，4，7 3*n+12，5，8 3*n+2acceptacceptP1a

4、ccept acceptP2acceptacceptP3acceptMencious全局事務(wù)的排序Paxos InstancePaxos Instance No.Paxos Msg全局事務(wù)的排序全局事務(wù)的排序存在問題：用戶請(qǐng)求不均衡，集群處理速 度受限于集群中處理最慢的節(jié) 點(diǎn)成員節(jié)點(diǎn)宕機(jī)或者出現(xiàn)網(wǎng)絡(luò)分 區(qū)，無法發(fā)送Skip，導(dǎo)致其他 節(jié)點(diǎn)日志無法提交解決方案：基于邏輯時(shí)鐘，慢的節(jié)點(diǎn)收到 快節(jié)點(diǎn)的suggest請(qǐng)求，Skip 當(dāng) 前序號(hào)到請(qǐng)求序號(hào)之間的請(qǐng)求 序列由被選舉的新的節(jié)點(diǎn)接管提案 權(quán)力，將新節(jié)點(diǎn)未被宕機(jī)節(jié)點(diǎn)learned到宕機(jī)節(jié)點(diǎn)序號(hào)之間的提案需要重新提議成員節(jié)點(diǎn)的管理沖突檢測機(jī)制），W

5、rite set：每個(gè)事務(wù)新增加一個(gè)Log Event（Transaction_context_log_event）包含信息事務(wù)更新的主鍵數(shù)據(jù)庫快照版本(gtid_executed)只在內(nèi)存中維護(hù)，不寫入binlog 文件，保證兼容性沖突檢測：每個(gè)成員節(jié)點(diǎn)按照相同的次序（Paxox協(xié)議保障 分別進(jìn)行沖突檢測每個(gè)成員節(jié)點(diǎn)都維護(hù)了一個(gè)“沖突檢測數(shù)據(jù)庫” 所有待檢測的事務(wù)對(duì)應(yīng)的數(shù)據(jù)庫版本必須大于沖 突檢測數(shù)據(jù)庫中已經(jīng)通過檢測的記錄的版本所有節(jié)點(diǎn)都已經(jīng)執(zhí)行的事務(wù)對(duì)應(yīng)的記錄會(huì)從沖突 檢測數(shù)據(jù)庫中異步purge節(jié)點(diǎn)流控為什么要引入流控機(jī)制：確保集群內(nèi)各個(gè)節(jié)點(diǎn)的延遲 盡可能的小避免Fail over時(shí)rel

6、ay log 回放 時(shí)間過長流控機(jī)制：檢測對(duì)象：事務(wù)個(gè)數(shù)作用對(duì)象：本節(jié)點(diǎn)寫事務(wù)調(diào)控周期：默認(rèn)1秒深入MySQL Group Replication01基于MGR 多副本高可用集群架構(gòu)設(shè)計(jì)基于MGR Muti-Primary水平擴(kuò)展基于MGR的跨機(jī)房高可用實(shí)踐020304基于MGR的高可用架構(gòu)設(shè)計(jì)MGR 提供了什么？基于Paxos協(xié)議實(shí)現(xiàn)的數(shù)據(jù)同步宕機(jī)自動(dòng)選主多節(jié)點(diǎn)寫入的沖突檢測Failover后集群內(nèi)數(shù)據(jù)修復(fù)基于write set 的并行復(fù)制MGR 沒有提供什么？客戶端的切換方案新成員節(jié)點(diǎn)加入，Donar節(jié)點(diǎn)隨機(jī)復(fù)制延遲大事務(wù)支持不足，容易OOM新節(jié)點(diǎn)加入，SST 不支持基于MGR的高可用架構(gòu)

7、設(shè)計(jì)客戶端切換：Replication_group_members 識(shí)別主從切換通過group_replication_weight 影響選主等待所有遠(yuǎn)端同步的日志回放Count_transactions_in_queue + Count_transactions_remote_in_applier_queu e管控服務(wù)通過調(diào)用彈性網(wǎng)關(guān)服務(wù)切換客戶 端的狀態(tài)故障切換的修復(fù)重啟實(shí)例，加入集群在Secondary 全量備份，重新加入集群R/WRAvaliable ZoneAvaliable ZoneAvaliable ZoneRDS VPCPrimary10.172.15.2Secondary10

8、.172.15.3Secondary10.172.15.4192.168.5.12192.168.8.16ApplicationCustomer VPC基于MGR的Single-Primary 方案Secondary 讀到過舊的數(shù)據(jù)，最終數(shù)據(jù)一致性大事務(wù)導(dǎo)致OOMSingle-Primary 沖突檢測不需要，但是并行復(fù)制需要，可以限制沖突檢測數(shù) 據(jù)庫大小流控Group_replication_flow_control_applier_threshold/certifier_threshold網(wǎng)易針對(duì)MGR 做的功能增強(qiáng)（一）當(dāng)前的問題：沖突檢測數(shù)據(jù)庫占用過多內(nèi)存導(dǎo)致數(shù)據(jù)庫OOM Crash問題

9、的原因：MGR 各個(gè)節(jié)點(diǎn)每隔60s 廣播各個(gè)節(jié)點(diǎn)的gtid_exected各個(gè)節(jié)點(diǎn)取交接后形成stable_gtid_set當(dāng)沖突檢測數(shù)據(jù)庫中每個(gè)Row對(duì)應(yīng)的gtid_set是stable_gtid_set子集時(shí)，可 以清理新的技術(shù)方案：Single-Primary 模式下或者中間件層已經(jīng)能夠確保事務(wù)不沖突的場景下不 需要沖突檢測直接根據(jù)Write set 個(gè)數(shù)清理網(wǎng)易針對(duì)MGR 做的功能增強(qiáng)（二）當(dāng)前的問題：沖突檢測數(shù)據(jù)庫中Write set過 多導(dǎo)致性能抖動(dòng)問題的原因：原有流控方案是針對(duì)事務(wù)的， 對(duì)于一個(gè)事務(wù)更多多個(gè)記錄， 會(huì)導(dǎo)致沖突檢測數(shù)據(jù)庫write set 過多Write set 過

10、多導(dǎo)致清理會(huì)很慢， 鎖引發(fā)周期性能抖動(dòng)新的技術(shù)方案：針對(duì)Write set 流控機(jī)制深入MySQL Group Replication01基于MGR 多副本高可用集群架構(gòu)設(shè)計(jì)基于MGR Muti-Primary水平擴(kuò)展基于MGR的跨機(jī)房高可用實(shí)踐020304基于MGR Muti-Priamry 方案解決了什么問題？單點(diǎn)寫入性能瓶頸Secondary 資源浪費(fèi)存在什么缺陷？如果存在大量沖突會(huì)導(dǎo)致性能很差不管是否存在沖突都必須要進(jìn)行沖 突檢測DDB + Single Primary MGR優(yōu)勢：數(shù)據(jù)庫單表水平擴(kuò)展每個(gè)Shard兩個(gè)副本高可用 劣勢：高可用備節(jié)點(diǎn)資源浪費(fèi)數(shù)據(jù)副本的重建耗時(shí)高同步復(fù)制網(wǎng)絡(luò)容忍性低DDB + Muti-Priamry MGR每個(gè)Shard 三個(gè)副本，只有一個(gè) 提供讀寫服務(wù)，副本之間基于Paxos 協(xié)議實(shí)現(xiàn)數(shù)據(jù)同步MGR 集群內(nèi)每個(gè)節(jié)點(diǎn)都承擔(dān)了一 部分Shard的讀寫，充分利用每個(gè)節(jié) 點(diǎn)的資源任意一個(gè)節(jié)點(diǎn)宕機(jī)，請(qǐng)求被分配 到不同節(jié)點(diǎn)上，重建通過不同Donar 節(jié)點(diǎn)，速度提升DDB + Muti-Pr