78C36620 23AE 3931 A620 03FF6FC1C1DA

1. T E 网易考拉基于MGR的跨机房实践 N . B U P IT 网易 郭忆

2. T E N . B 01 深入MySQL Group Replication 02 基于MGR 多副本高可用集群架构设计 02 03 基于MGR Muti-Primary水平扩展方案 02 04 基于MGR的跨机房高可用实践 IT U P

3. MySQL 数据库的高可用发展历程 Share Nothing Master-Slave Rpl Share Storage MMM DRBD MHA Loss-Less Rpl Binlog DW Aurora Galera SAN MGR PolarDB

4. MySQL Group Replication 多副本数据库集群面临的挑战 • • • • • MySQL 5.7.17 Release A new MySQL Plugin Muti-Duplicate Cluster Data Consistency Single/Muti-Primary mode 全局事务的排序 Mencious 成员节点的管理 Group View 冲突检测机制 Write Set 节点处理能力协同 Flow Control

5. MGR 事务提交处理流程 Client • • • • • • • • • • Client Execute DML Native Processing Before Commit Hook GTID Allocated Create WriteSet Flow Control Paxos Instance Certification Write Relay Log Parallel Replay Other Server Server UPDATE Other Server Native Processing OK COMMIT Paxos Certification OK Certification Not OK Commit OK Not OK Commit rollback Certification OK Not OK Commit rollback rollback

6. accept 全局事务的排序 0，3，6… 3*n prepare A prepare accept Basic Paxos A accept A 1，4，7… 3*n+1 P accept P accept accept A A P1 accept P P2 accept A 2，5，8… 3*n+2 Raft/Multi Paxos A A A A accept A accept A P3 Mencious

7. 全局事务的排序 Paxos Instance Paxos Instance No. Paxos Msg

8. 全局事务的排序

9. 全局事务的排序 存在问题： • 用户请求不均衡，集群处理速 度受限于集群中处理最慢的节 点 • 成员节点宕机或者出现网络分 区，无法发送Skip，导致其他 节点日志无法提交 解决方案： • 基于逻辑时钟，慢的节点收到 快节点的suggest请求，Skip 当 前序号到请求序号之间的请求 序列 • 由被选举的新的节点接管提案 权力，将新节点未被宕机节点 learned到宕机节点序号之间的 提案需要重新提议

10. 成员节点的管理

11. 冲突检测机制 Write set： • 每个事务新增加一个Log Event （Transaction_context_log_event） • 包含信息 • 事务更新的主键 • 数据库快照版本(gtid_executed) • 只在内存中维护，不写入binlog 文件，保证兼容性 冲突检测： • 每个成员节点按照相同的次序（Paxox协议保障）， 分别进行冲突检测 • 每个成员节点都维护了一个“冲突检测数据库”， 所有待检测的事务对应的数据库版本必须大于冲 突检测数据库中已经通过检测的记录的版本 • 所有节点都已经执行的事务对应的记录会从冲突 检测数据库中异步purge

12. 节点流控 为什么要引入流控机制： • 确保集群内各个节点的延迟 尽可能的小 • 避免Fail over时relay log 回放 时间过长 流控机制： • 检测对象：事务个数 • 作用对象：本节点写事务 • 调控周期：默认1秒

13. 01 深入MySQL Group Replication 02 基于MGR 多副本高可用集群架构设计 02 03 基于MGR Muti-Primary水平扩展 02 04 基于MGR的跨机房高可用实践

14. 基于MGR的高可用架构设计 MGR 提供了什么？ MGR 没有提供什么？ • 基于Paxos协议实现的数据同步 • 客户端的切换方案 • 宕机自动选主 • 新成员节点加入，Donar节点随机 • 多节点写入的冲突检测 • 复制延迟 • Failover后集群内数据修复 • 大事务支持不足，容易OOM • 基于write set 的并行复制 • 新节点加入，SST 不支持

15. 基于MGR的高可用架构设计 客户端切换： • Replication_group_members 识别主从切换 • 通过group_replication_weight 影响选主 • 等待所有远端同步的日志回放 Count_transactions_in_queue + Count_transactions_remote_in_applier_queu e • 管控服务通过调用弹性网关服务切换客户 端的状态 故障切换的修复 • 重启实例，加入集群 • 在Secondary 全量备份，重新加入集群 Customer VPC Application R/W RDS VPC R 192.168.8.16 192.168.5.12 Primary 10.172.15.2 Avaliable Zone Secondary 10.172.15.3 Avaliable Zone Secondary 10.172.15.4 Avaliable Zone

16. 基于MGR的Single-Primary 方案 • Secondary 读到过旧的数据，最终数据一致性 • 大事务导致OOM • Single-Primary 冲突检测不需要，但是并行复制需要，可以限制冲突检测数 据库大小 • 流控 • Group_replication_flow_control_applier_threshold/certifier_threshold

17. 网易针对MGR 做的功能增强（一） 当前的问题： • 冲突检测数据库占用过多内存导致数据库OOM Crash 问题的原因： • MGR 各个节点每隔60s 广播各个节点的gtid_exected • 各个节点取交接后形成stable_gtid_set • 当冲突检测数据库中每个Row对应的gtid_set是stable_gtid_set子集时，可 以清理 新的技术方案： • Single-Primary 模式下或者中间件层已经能够确保事务不冲突的场景下不 需要冲突检测 • 直接根据Write set 个数清理

18. 网易针对MGR 做的功能增强（二） 当前的问题： • 冲突检测数据库中Write set过 多导致性能抖动 问题的原因： • 原有流控方案是针对事务的， 对于一个事务更多多个记录， 会导致冲突检测数据库write set 过多 • Write set 过多导致清理会很慢， 锁引发周期性能抖动 新的技术方案： • 针对Write set 流控机制

19. 01 深入MySQL Group Replication 02 基于MGR 多副本高可用集群架构设计 02 03 基于MGR Muti-Primary水平扩展 02 04 基于MGR的跨机房高可用实践

20. 基于MGR Muti-Priamry 方案 解决了什么问题？ 存在什么缺陷？ • 单点写入性能瓶颈 • 如果存在大量冲突会导致性能很差 • Secondary 资源浪费 • 不管是否存在冲突都必须要进行冲 突检测

21. DDB + Single Primary MGR 优势： • 数据库单表水平扩展 • 每个Shard两个副本高可用 劣势： • 高可用备节点资源浪费 • 数据副本的重建耗时高 • 同步复制网络容忍性低

22. DDB + Muti-Priamry MGR • 每个Shard 三个副本，只有一个 提供读写服务，副本之间基于Paxos 协议实现数据同步 • MGR 集群内每个节点都承担了一 部分Shard的读写，充分利用每个节 点的资源 • 任意一个节点宕机，请求被分配 到不同节点上，重建通过不同Donar 节点，速度提升

23. DDB + Muti-Priamry MGR

24. 01 深入MySQL Group Replication 02 基于MGR 多副本高可用集群架构设计 02 03 基于MGR Muti-Primary水平扩展 02 04 基于MGR的跨机房高可用实践

25. 同城双机房部署方案的选择

26. 网易考拉基于MGR的同城跨机房高可用架构设计

27. 基于MGR的异地跨城容灾

28. 基于MGR的异地跨城容灾

29. 基于MGR的异地跨城容灾

30.