基于MGR的数据高可用架构

全局事务的排序 成员节点的管理 冲突检测机制 节点处理能力协同
Mencious Group View
Write Set Flow Control
• Client Execute DML • Native Processing • Before Commit Hook • GTID Allocated • Create WriteSet
时间过长
流控机制： • 检测对象：事务个数 • 作用对象：本节点写事务 • 调控周期：默认1秒
01 深入MySQL Group Replication
02 基于MGR 多副本高可用集群架构设计
03 基于MGR Muti-Primary水平扩展 04 基于MGR的跨机房高可用实践
基于MGR的高可用架构设计
OK
Not OK
Commit
rollback
Other Server
Other Server
Certification
Certification
OK
Not OK OK
Not OK
Commit
Commit
rollback
rollback
prepare A
P prepare A
accept
A
P
accept
网易考拉基于MGR的高可用架构
技术创新 变革未来
01 深入MySQL Group Replication
02 基于MGR 多副本高可用集群架构设计 03 基于MGR Muti-Primary水平扩展方案 04 基于MGR的跨机房高可用实践
MySQL 数据库的高可用发展历程
Share Nothing
基于MGR的高可用架构设计
客户端切换： • Replication_group_members 识别主从切换 • 通过group_replication_weight 影响选主 • 等待所有远端同步的日志回放
Count_transactions_in_queue + Count_transactions_remote_in_applier_queu e
• Flow Control • Paxos Instance • Certification • Write Relay Log • Parallel Replay
MGR 事务提交处理流程
Client
Server UPDATE
OK Native Process ng i
COMMIT
Paxos
Certification
AHale Waihona Puke Baidu
Basic Paxos
全局事务的排序
accept
A
0，3，6… 3*n P1
accept
A
accept
A
accept
A
1，4，7… 3*n+1
P2
P
A accept
accept
A
accept
A
2，5，8… 3*n+2 P3
accept
A
Raft/Multi Paxos
Mencious
Paxos Instance Paxos Instance No.
• 流控 • Group_replication_flow_control_applier_threshold/certifier_threshold
• 由被选举的新的节点接管提案 权力，将新节点未被宕机节点 learned到宕机节点序号之间的 提案需要重新提议
成员节点的管理
冲突检测机制
Write set： • 每个事务新增加一个Log Event
（Transaction_context_log_event） • 包含信息 • 事务更新的主键 • 数据库快照版本(gtid_executed) • 只在内存中维护，不写入binlog 文件，保证兼容性 冲突检测： • 每个成员节点按照相同的次序（Paxox协议保障），
Share Storage
Master-Slave Rpl
MMM
MHA
Loss-Less Rpl Binlog DW
Galera
MGR
DRBD
SAN
Aurora
PolarDB
MySQL Group Replication
多副本数据库集群面临的挑战
• MySQL 5.7.17 Release • A new MySQL Plugin • Muti-Duplicate Cluster • Data Consistency • Single/Muti-Primary mode
10.172.15.3
Avaliable Zone
192.168.8.16
Secondary
10.172.15.4
Avaliable Zone
基于MGR的Single-Primary 方案
• Secondary 读到过旧的数据，最终数据一致性 • 大事务导致OOM
• Single-Primary 冲突检测不需要，但是并行复制需要，可以限制冲突检测数 据库大小
分别进行冲突检测 • 每个成员节点都维护了一个“冲突检测数据库”，
所有待检测的事务对应的数据库版本必须大于冲 突检测数据库中已经通过检测的记录的版本 • 所有节点都已经执行的事务对应的记录会从冲突 检测数据库中异步purge
节点流控
为什么要引入流控机制： • 确保集群内各个节点的延迟
尽可能的小 • 避免Fail over时relay log 回放
• 管控服务通过调用弹性网关服务切换客户 端的状态
故障切换的修复
• 重启实例，加入集群 • 在Secondary 全量备份，重新加入集群
Customer VPC
Application
R/W
R
RDS VPC
192.168.5.12
Primary
10.172.15.2
Avaliable Zone
Secondary
MGR 提供了什么？ • 基于Paxos协议实现的数据同步 • 宕机自动选主 • 多节点写入的冲突检测 • Failover后集群内数据修复 • 基于write set 的并行复制
MGR 没有提供什么？ • 客户端的切换方案 • 新成员节点加入，Donar节点随机 • 复制延迟 • 大事务支持不足，容易OOM • 新节点加入，SST 不支持
Paxos Msg
全局事务的排序
全局事务的排序
全局事务的排序
存在问题：
• 用户请求不均衡，集群处理速 度受限于集群中处理最慢的节 点
• 成员节点宕机或者出现网络分 区，无法发送Skip，导致其他 节点日志无法提交
解决方案：
• 基于逻辑时钟，慢的节点收到 快节点的suggest请求，Skip 当 前序号到请求序号之间的请求 序列