1、網易考拉基于MGR的高可用架構技術創新 變革未來深入MySQL Group Replication01基于MGR 多副本高可用集群架構設計基于MGR Muti-Primary水平擴展方案基于MGR的跨機房高可用實踐020304MySQL 數據庫的高可用發展歷程Share NothingShare StorageMaster-Slave RplMMMMHALoss-Less RplBinlog DWGaleraMGRDRBDAuroraPolarDBSANMySQL Group Replication多副本數據庫集群面臨的挑戰全局事務的排序成員節點的管理沖突檢測機制節點處理能力協同MySQL 5

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

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

4、ccept acceptP2acceptacceptP3acceptMencious全局事務的排序Paxos InstancePaxos Instance No.Paxos Msg全局事務的排序全局事務的排序存在問題：用戶請求不均衡，集群處理速 度受限于集群中處理最慢的節 點成員節點宕機或者出現網絡分 區，無法發送Skip，導致其他 節點日志無法提交解決方案：基于邏輯時鐘，慢的節點收到 快節點的suggest請求，Skip 當 前序號到請求序號之間的請求 序列由被選舉的新的節點接管提案 權力，將新節點未被宕機節點learned到宕機節點序號之間的提案需要重新提議成員節點的管理沖突檢測機制），W

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

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

7、設計客戶端切換：Replication_group_members 識別主從切換通過group_replication_weight 影響選主等待所有遠端同步的日志回放Count_transactions_in_queue + Count_transactions_remote_in_applier_queu e管控服務通過調用彈性網關服務切換客戶 端的狀態故障切換的修復重啟實例，加入集群在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 讀到過舊的數據，最終數據一致性大事務導致OOMSingle-Primary 沖突檢測不需要，但是并行復制需要，可以限制沖突檢測數 據庫大小流控Group_replication_flow_control_applier_threshold/certifier_threshold網易針對MGR 做的功能增強（一）當前的問題：沖突檢測數據庫占用過多內存導致數據庫OOM Crash問題

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

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