云数据库高可用解决方案技术解析
|
普通的异步复制对数据库性能影响小,但是主从数据一致性难以保证；强同步复制虽然保证了主从强一致,但是可用性很差；因此udb选择了折中的方案即半同步复制,但只是简单的使用半同步复制还是不够,通过分析半同步复制的过程和原理,会发现半同步复制会存在以下一些缺陷,下面将分析缺陷的同时介绍下udb的解决方案和策略： 1、临界事务问题? 什么是临界事务,临界事务就是在宕机那个时间点主库正在提交的事务,这个事务可能已经提交,可能已经fsync到磁盘,但是确没有同步到从库中去,半同步复制对于临界事务是没法保证的,如下图是myql5.7无损复制一次事务commit流程(udb基于次复制技术做了优化)： 如上图,我们对5.7版本中的无损复制模式(默认模式下)的半同步复制的主机commit做了细分,拆成7个可能crash的阶段,考虑到双机切换后可能会导致的数据丢失和数据一致性异常,我们对每个阶段有如下分析：
通过以上分析,无损复制模式下只有在阶段4发生宕机会导致恢复后双主数据不一致,因为当在此阶段发生宕机,该事务并没有发送至从库,但是主库已提交至Binlog和Redolog,如果此时业务切至从库,主库恢复后会继续将事务commit并同步到从库,但是由于从库上已经有了新事务,很可能会和此事务产生冲突(如主键冲突),从而导致双主数据不一致；为了解决此宕机时临界事务问题,我们通过内核层面在主库重启recovery阶段作了如下调整：有选择性的commit并复制到从库部分事务,回滚掉没有同步到原从库的事务及Truncate掉binlog中相应的event,整个过程如下图： 如上图所示,主库在恢复后,会向从库或者proxy询问从本库同步过去的最后一条事务的Binlog位置,并以此为基础回滚掉该Binlog位置之后的临界事务. 2、半同步退化问题? 由于网络抖动以及从库硬件故障等问题会导致半同步退化为异步,如果在此情况下主库发生宕机并发生切换,会导致数据丢失,对于很多数据敏感的业务(如金融)后果是非常严重的；因此当半同步复制退化,整个集群是不可以容灾切换业务的；但是如果主机宕机无法ssh登陆,我们又如何确定主从是否退化,从库数据是否和主库一致呢. 为了解决此问题,防止错误的切换导致数据丢失,UDB通过在proxy和mysql之间以及主从之间增加链接通道,proxy和myql会用专门的线程通过此链接通道同步事务信息,如果主库发生宕机,从库可以在本地缓存和远端proxy获取同步事务信息,并使用该事务信息作为从机是否可以切换的依据,如下图： 同时为了提高可用性,应对短时间网络抖动后造成双主长时间数据不一致,udb在网络恢复后,会额外启动一个复制链路来追补落后的数据,而原半同步复制链路继续用于复制实时事务,这样不仅可以加快复制数据效率,而且避免了由于从库负载过高永远恢复半同步的风险. 3、如何保证proxy的高可用 通过以上问题及UDB相应解决方案的分析,大家可以看出Proxy在整个架构中扮演着极其重要的角色,不仅负责数据转发,同时为数据一致性和可用性提高保障；因此大家一定会问如果Proxy宕机怎么办,为了解决Proxy高可用问题,UDB这边对Proxy模块也采用了一主一备模式,如下图： 主Proxy宕机触发容灾 当图中左路主Proxy宕机后,ProxyMaster模块会触发容灾处理过程,此时ProxyMaster会将虚拟IP重新绑定至Proxy(backup)并自动启动,启动后Proxy(backup)会重新链路至原MasterDB,以保证业务不间断,而ProxyMaster模块通过ZK服务分布在多个服务器上,有效的保证了Proxy的可用性. 当然除了该双主技术架构外,为了保障服务的高可用,UDB在运维监控等层面也做了很多工作,通过对从硬件、操作系统、数据库以及网络等各个层面的不间断监控,从而最大程度的及时捕获和恢复数据库服务；同时UDB通过自研的大型数据库备份系统,能够应对各种级别的宕机故障后的数据恢复,从而保障了用户数据的安全可靠性,这里不做过多赘述,有兴趣的同学可以参考《从炉石传说数据库故障看云数据备份策略》这篇文章. 作者介绍孙研,UCloud云数据库UDB团队核心成员、高级研发工程师,带领团队对UDB底层架构进行重构,在内核方面对UDB性能和数据一致性等方面做了大量深入的工作.数年来深耕在云数据库领域,热衷于开源、分享. 文章来自微信公众号：细说云计算 （编辑：江门站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
