1、,数据库高可用架构设计,技术创新,变革未来,数据库高可用发展历程,目录,Aurora 高可用架构设计MGR 高可用架构设计多副本数据一致高可用架构设计,PART 01 数据库高可用发展历程,基于复制的数据库高可用架构,Pros,原生支持 快速部署,易维护 同步复制可以确保数据一致,Cons 异步复制丢数据 同步复制无法支撑写密集业务 复制延迟,基于日志的数据库高可用架构,Master,Slave,Slave (lastest),Slave,MHA,Binary log,Differ binary log,Master,Slave,共享存储,Replication,Double Write,Bi
2、nlog double write,Pros 限定条件下能够保证数据的一致性,Cons MHA: 主机服务器SSH无法访问丢数据 日志双写:异步状态下丢数据,基于块设备镜像的数据库高可用,Pros,对数据库透明 通用高可用解决方案,Cons 性能无法满足 跨网络流量,Page Cache,File System,DRBD,IO Scheduler,Disk Driver,Page Cache,File System,DRBD,IO Scheduler,Disk Driver,DRBD,Primary,Replica,Shared nothing 多副本高可用架构,Client,T1,Clien
3、t,T2,Client,T3,T2 T1 T3,T2 T1,T3,T2 T1,T3,数据处理模块,事务分发模块,Paxos,Pros Shared nothing 多副本,金融级可靠性 支持多写,解决写扩展问题,Cons 基于binlog的数据同步,复制延迟难以 避免 多写模式下所有的事务提交都必须要冲 突检测,即使没有冲突,MGR,Cloud-Native Database,Applications,SQL,Transactions,Cache,Loging,SQL,Transactions,Cache,Loging,Storage,Aurora,PolarDB,Pros Shared di
4、sk cluster 计算和存储分离,解决扩展性 方案具有通用性 获得更好的性能,Cons 技术门槛高 强依赖于底层基础设施,PART 02 Aurora 高可用设计,为什么要有Aurora?,跨网络传输的数据 Redo log Binlog Data Page Double Write FRM所有数据要跨网络传输5次, 其中3次传输还是串行的,Aurora,统一的跨可用区、多副本、 高可用的共享存储系统 数据库实例和存储系统仅通 过redo同步数据 Cache 之间通过redo 同步 减少时延 Recovery 异步执行,秒级 恢复,Storage Design,数据库实例的存储由10G 大
5、小的 Segment组成 每个Segment 有6个副本,分布在 3个可用域 存储节点是由挂载了本地SSD的 EC2组成 单个数据库最大支持64 TB Segment是存储系统数据修复的最 小单元 通过标记Segment不可用完成计划 内的迁移操作(热点不均衡),Quorum Design,Quorum a write quorum of 4/6 (Vw = 4) a read quorum of 3/6 (Vr = 3) 容错性 失去整个可用域和另外的一个存 储节点,不影响整体系统的读可 用性 失去任意两个节点,包括同一个 可用域或者不同可用域,不影响 写可用,事务提交,redo log在m
6、tr提交时copy log buffer Log record 根据page所在的存储节点 分成多个batch,然后发送到对应的存 储节点 如果一个PG内的6个Segment中4个写 入成功,则数据库返回客户端事务提交 成功,同时推动VDL 每个Page 根据待更新的redo log record长度决定page materialization 同一个PG内的不同Segment 通过 Gossip协议补全日志,故障恢复,CPL : 每个mtr 最后一个log record对应的lsn VCL:持久化的最大的log record lsn VDL:小于VCL 的最大的CPL Recovry的过程只
7、需要建立 VDL即可,与MySQL 回放 redo 不同 未提交事务异步回滚,Muti-Master,冲突检测,以Page为粒度进行冲突检 测 基于lsn 实现版本管理和冲 突检测 利用逻辑时钟(Lamport Clock)解决因果关系的事 务顺序执行问题 基于Quorum原则,最先写 成功4个的事务提交,冲突 事务回滚,Master 1,Master 2,PageID:1 Lsn: 100uuid1,Aurora Storage,PageID:1 Lsn: 100uuid1,PageID:1 Lsn: 100uuid1,PART 03 MySQL Group Replication,MGR,
8、MySQL 5.7.17 发布 基于Paxos 协议实现的多副本数 据一致性集群 支持single-master 模式和 multi-master模式 作为MySQL Innodb cluster 解 决方案一部分,MGR 基本原理,所有节点都有相同的数据 副本 基于binlog实现数据的同 步 本地事务提交时,进入全 局排序 基于Paxos协议确保集群内 所有节点按照相同的事务 次序执行 所有事务基于write set 进 行冲突检测,Client,Server,UPDATE,Native Processing,OK,COMMIT,Other Server,Other Server,Cert
9、ification,Paxos,Certification,Certification,Commit,rollback,Commit,rollback,Commit,rollback,OK,OK,OK,Not OK,Not OK,Not OK,一致性协议,P,A,A,prepare,prepare,P,A,A,accept,accept,P,A,A,accept,P,P,Mencius,优势:,相比Basic Paxos 节约了Prepare阶段 的性能开销 相比Muti-Paxos 消除Leader 瓶颈, 每个成员负责一部分的提议,0,3,6 3*n,1,3,5 3*n+1,1,3,5 3
10、*n+2,Basic Paxos 优势:任意节点都可以发起提议 劣势: 每个value都需要至少2次网络开销,2次磁盘持久化 容易产生活锁,Write set,Write set: 每个事务新增加一个Log Event(Transaction_context_log_event) 包含信息 事务更新的主键 数据库快照版本(gtid_executed) 只在内存中维护,不写入binlog 文件,保证兼容性冲突检测: 每个成员节点按照相同的次序(Paxox协议保障),分别进行冲突检测 每个成员节点都维护了一个“冲突检测数据库”,所有待检测的事务对应的数据库版本必须大于冲 突检测数据库中已经通过检测
11、的记录的版本 所有节点都已经执行的事务对应的记录会从冲突检测数据库中异步purge,冲突检测,T1,T2,T1,T2,gtid_executed: group:1-100,gtid_executed: group:1-100,T1通过冲突检测,Update s1 set c2 = 5 where pk =1,Update s1 set c2 = 6 where pk =1,T1:,T2:,T1 gtid_executed : group:1-100,T2 gtid_executed : group:1-100,T2未通过冲突检测,回滚,PART 04 数据库高可用解决方案,云数据库架构,服务器
12、,硬盘设备,网络设备,虚拟机,云硬盘,云网络,RDS,DDB,NDC,数据库助手,工具链,RDS,RDS,基础版,双机高可用版,多副本高可用,基于MGR 多副本数据库高可用架构,三个节点位于三个可用 域内,物理隔离 基于RDS VPC 网络实现 集群内的数据同步 提供读写和只读两个域 名 三节点中设置一个只读 节点 通过权重影响节点切换 策略,R/W,R,Avaliable Zone,Primary,Avaliable Zone,Secondary,Avaliable Zone,RDS VPC,10.172.15.2,10.172.15.3,Secondary 10.172.15.4,192.
13、168.5.12,192.168.8.16,Application,Customer VPC,故障恢复,Failover time = election time + apply time 故障节点修复后重新加入集群,选择只读节点作为Seed 控制只读能力,尽快完成数据的修复,流控设计,参数,group_replication_flow_ control_mode group_replication_flow_ control_certifier_thresh old group_replication_flow_ control_applier_thresho ld,T5 T4 T3,T5 T4 T3,T2 T1,T5 T4 T3 T2,T1,Certifier Queue,Applier Queue,性能表现,