搜索
数据库高可用架构设计技术创新，变革未来数据库高可用发展历程目录Aurora高可用架构设计MGR高可用架构设计多副本数据一致高可用架构设计PART01数据库高可用发展历程基于复制的数据库高可用架构Pros•原生支持•快速部署，易维护•同步复制可以确保数据一致Cons•异步复制丢数据•同步复制无法支撑写密集业务•复制延迟基于日志的数据库高可用架构MasterSlaveSlave（lastest）SlaveMHABinarylogDifferbinarylogMasterSlave共享存储ReplicationDoubleWriteBinlogdoublewritePros•限定条件下能够保证数据的一致性Cons•MHA：主机服务器SSH无法访问丢数据•日志双写：异步状态下丢数据基于块设备镜像的数据库高可用Pros•对数据库透明•通用高可用解决方案Cons•性能无法满足•跨网络流量PageCacheFileSystemDRBDIOSchedulerDiskDriverPageCacheFileSystemDRBDIOSchedulerDiskDriverDRBDPrimaryReplicaSharednothing多副本高可用架构ClientT1ClientT2ClientT3T2T1T3T2T1T3T2T1T3数据处理模块事务分发模块PaxosPros•Sharednothing•多副本，金融级可靠性•支持多写，解决写扩展问题Cons•基于binlog的数据同步，复制延迟难以避免•多写模式下所有的事务提交都必须要冲突检测，即使没有冲突MGRCloud-NativeDatabaseApplicationsSQLTransactionsCacheLogingSQLTransactionsCacheLogingStorageAuroraPolarDBPros•Shareddiskcluster•计算和存储分离，解决扩展性•方案具有通用性•获得更好的性能Cons•技术门槛高•强依赖于底层基础设施PART02Aurora高可用设计为什么要有Aurora?•跨网络传输的数据•Redolog•Binlog•DataPage•DoubleWrite•FRM•所有数据要跨网络传输5次，其中3次传输还是串行的Aurora•统一的跨可用区、多副本、高可用的共享存储系统•数据库实例和存储系统仅通过redo同步数据•Cache之间通过redo同步减少时延•Recovery异步执行，秒级恢复StorageDesign•数据库实例的存储由10G大小的Segment组成•每个Segment有6个副本，分布在3个可用域•存储节点是由挂载了本地SSD的EC2组成•单个数据库最大支持64TB•Segment是存储系统数据修复的最小单元•通过标记Segment不可用完成计划内的迁移操作（热点不均衡）QuorumDesign•Quorum•awritequorumof4/6(Vw=4)•areadquorumof3/6(Vr=3)•容错性•失去整个可用域和另外的一个存储节点，不影响整体系统的读可用性•失去任意两个节点，包括同一个可用域或者不同可用域，不影响写可用事务提交•redolog在mtr提交时copylogbuffer•Logrecord根据page所在的存储节点分成多个batch，然后发送到对应的存储节点•如果一个PG内的6个Segment中4个写入成功，则数据库返回客户端事务提交成功，同时推动VDL•每个Page根据待更新的redologrecord长度决定pagematerialization•同一个PG内的不同Segment通过Gossip协议补全日志故障恢复•CPL：每个mtr最后一个logrecord对应的lsn•VCL：持久化的最大的logrecordlsn•VDL：小于VCL的最大的CPL•Recovry的过程只需要建立VDL即可，与MySQL回放redo不同•未提交事务异步回滚Muti-Master•冲突检测•以Page为粒度进行冲突检测•基于lsn实现版本管理和冲突检测•利用逻辑时钟（LamportClock）解决因果关系的事务顺序执行问题•基于Quorum原则，最先写成功4个的事务提交，冲突事务回滚Master1Master2PageID：1Lsn:100uuid1AuroraStoragePageID：1Lsn:100uuid1PageID：1Lsn:100uuid1PART03MySQLGroupReplicationMGR•MySQL5.7.17发布•基于Paxos协议实现的多副本数据一致性集群•支持single-master模式和multi-master模式•作为MySQLInnodbcluster解决方案一部分MGR基本原理•所有节点都有相同的数据副本•基于binlog实现数据的同步•本地事务提交时，进入全局排序•基于Paxos协议确保集群内所有节点按照相同的事务次序执行•所有事务基于writeset进行冲突检测ClientServerUPDATENativeProcessingOKCOMMITOtherServerOtherServerCertificationPaxosCertificationCertificationCommitrollbackCommitrollbackCommitrollbackOKOKOKNotOKNotOKNotOK一致性协议PAApreparepreparePAAacceptacceptPAAacceptPPMencius•优势：•相比BasicPaxos节约了Prepare阶段的性能开销•相比Muti-Paxos消除Leader瓶颈，每个成员负责一部分的提议0，3，6…3*n1，3，5…3*n+11，3，5…3*n+2BasicPaxos•优势：任意节点都可以发起提议•劣势：•每个value都需要至少2次网络开销，2次磁盘持久化•容易产生活锁Writeset•Writeset：•每个事务新增加一个LogEvent（Transaction_context_log_event）•包含信息•事务更新的主键•数据库快照版本(gtid_executed)•只在内存中维护，不写入binlog文件，保证兼容性•冲突检测：•每个成员节点按照相同的次序（Paxox协议保障），分别进行冲突检测•每个成员节点都维护了一个“冲突检测数据库”，所有待检测的事务对应的数据库版本必须大于冲突检测数据库中已经通过检测的记录的版本•所有节点都已经执行的事务对应的记录会从冲突检测数据库中异步purge冲突检测主键版本1group:1-100T1,T2T1T2gtid_executed:group:1-100gtid_executed:group:1-100T1通过冲突检测主键版本1group:1-101Updates1setc2=5wherepk=1Updates1setc2=6wherepk=1T1:T2:T1’gtid_executed:group:1-100T2’gtid_executed:group:1-100T2未通过冲突检测，回滚PART04数据库高可用解决方案云数据库架构服务器硬盘设备网络设备虚拟机云硬盘云网络RDSDDBNDC数据库助手工具链RDSRDS基础版双机高可用版多副本高可用基于MGR多副本数据库高可用架构•三个节点位于三个可用域内，物理隔离•基于RDSVPC网络实现集群内的数据同步•提供读写和只读两个域名•三节点中设置一个只读节点•通过权重影响节点切换策略R/WRAvaliableZonePrimaryAvaliableZoneSecondaryAvaliableZoneRDSVPC10.172.15.210.172.15.3Secondary10.172.15.4192.168.5.12192.168.8.16ApplicationCustomerVPC故障恢复•Failovertime=electiontime+applytime•故障节点修复后重新加入集群，选择只读节点作为Seed•控制只读能力，尽快完成数据的修复流控设计•参数•group_replication_flow_control_mode•group_replication_flow_control_certifier_threshold•group_replication_flow_control_applier_thresholdT5T4T3T5T4T3T2T1T5T4T3T2T1CertifierQueueApplierQueue性能表现