网易考拉基于MGR的跨机房实践.pptx

1、MGR网易考拉基于 的跨机房实践深入MySQL Group Replication01020304基于MGR 多副本高可用集群架构设计基于MGR Muti-Primary水平扩展方案基于MGR的跨机房高可用实践MySQL 数据库的高可用发展历程Share StorageShare NothingMaster-Slave RplMMMDRBDSANMHALoss-Less RplBinlog DWAuroraPolarDBGaleraMGRMySQL Group Replication全局事务的排序Mencious多副本数据库集群面临的挑战成员节点的管理冲突检测机制Group ViewWrite

2、 Set MySQL 5.7.17 Release A new MySQL Plugin Muti-Duplicate Cluster Data Consistency Single/Muti-Primary mode节点处理能力协同Flow ControlMGR 事务提交处理流程Other ServerOther ServerClientServerUPDATEOK Client Execute DML Native Processing Before Commit Hook GTID Allocated Create WriteSet Flow Control Paxos Instance

3、 Certification Write Relay LogNative ProcessingCOMMITPaxosCertificationCertificationNot OK OKCertificationNot OKOKOKCommitNot OKCommitCommitrollbackrollbackrollback Parallel ReplayacceptA全局事务的排序P10，3，6 3*nAprepareAacceptacceptAPPAacceptAAprepareaccept1，4，7 3*n+1P2P3APacceptacceptAacceptAAAaccept2，5，

4、8 3*n+2acceptBasic PaxosRaft/Multi PaxosMencious全局事务的排序Paxos InstancePaxos Instance No.Paxos Msg全局事务的排序全局事务的排序存在问题：用户请求不均衡，集群处理速度受限于集群中处理最慢的节点成员节点宕机或者出现网络分区，无法发送Skip，导致其他节点日志无法提交解决方案：基于逻辑时钟，慢的节点收到快节点的suggest请求，Skip 当前序号到请求序号之间的请求序列由被选举的新的节点接管提案权力，将新节点未被宕机节点learned到宕机节点序号之间的提案需要重新提议成员节点的管理冲突检测机制Write

5、 set：每个事务新增加一个Log Event（Transaction_context_log_event）包含信息事务更新的主键数据库快照版本(gtid_executed)只在内存中维护，不写入binlog 文件，保证兼容性冲突检测：每个成员节点按照相同的次序（Paxox协议保障）分别进行冲突检测每个成员节点都维护了一个“冲突检测数据库”，所有待检测的事务对应的数据库版本必须大于冲突检测数据库中已经通过检测的记录的版本所有节点都已经执行的事务对应的记录会从冲突检测数据库中异步purge节点流控为什么要引入流控机制： 确保集群内各个节点的延迟尽可能的小 避免Fail over时relay lo

6、g 回放时间过长流控机制： 检测对象：事务个数 作用对象：本节点写事务 调控周期：默认1秒深入MySQL Group Replication01020304基于MGR 多副本高可用集群架构设计基于MGR Muti-Primary水平扩展基于MGR的跨机房高可用实践基于MGR的高可用架构设计MGR 提供了什么？MGR 没有提供什么？ 基于Paxos协议实现的数据同步 宕机自动选主 客户端的切换方案 新成员节点加入，Donar节点随机 复制延迟 多节点写入的冲突检测 Failover后集群内数据修复 基于write set 的并行复制 大事务支持不足，容易OOM 新节点加入，SST 不支持基于MG

7、R的高可用架构设计客户端切换： Replication_group_members 识别主从切换 通过group_replication_weight 影响选主 等待所有远端同步的日志回放Count_transactions_in_queue +Count_transactions_remote_in_applier_queueCustomer VPCApplication 管控服务通过调用弹性网关服务切换客户端的状态R/WR故障切换的修复 重启实例，加入集群RDS VPC192.168.8.16192.168.5.12 在Secondary 全量备份，重新加入集群10.172.15.210.

8、172.15.310.172.15.4Avaliable ZoneAvaliable ZoneAvaliable Zone基于MGR的Single-Primary 方案 Secondary 读到过旧的数据，最终数据一致性 大事务导致OOM Single-Primary 冲突检测不需要，但是并行复制需要，可以限制冲突检测数据库大小 流控 Group_replication_flow_control_applier_threshold/certifier_threshold网易针对MGR 做的功能增强（一）当前的问题： 冲突检测数据库占用过多内存导致数据库OOM Crash问题的原因： MGR 各

9、个节点每隔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 Replication01020304基于MGR 多副本高可用集群架构设计基于MGR Muti-Primary水平扩展基于MGR的跨机房高可用实践基于MGR Muti-Priamry 方案存在什么缺陷？解决了什么问题？ 单点写入性能瓶颈 Secondary 资源浪费 如果存在大量冲突会导致性能很差 不管是否存在冲突都必须要进行冲突检测DDB + Single Primary MGR优势： 数据库单表水平扩展 每个Shard两个副本高可用劣势： 高可用备节点资源浪费 数据副本的重建耗时高 同步复制网络

11、容忍性低DDB + Muti-Priamry MGR 每个Shard 三个副本，只有一个提供读写服务，副本之间基于Paxos协议实现数据同步 MGR 集群内每个节点都承担了一部分Shard的读写，充分利用每个节点的资源 任意一个节点宕机，请求被分配到不同节点上，重建通过不同Donar节点，速度提升DDB + Muti-Priamry MGR深入MySQL Group Replication基于MGR 多副本高可用集群架构设计基于MGR Muti-Primary水平扩展01020304基于MGR的跨机房高可用实践同城双机房部署方案的选择网易考拉基于MGR的同城跨机房高可用架构设计基于MGR的异地跨城容灾基于MGR的异地跨城容灾基于MGR的异地跨城容灾