高可用架构实践云数据库

1、 UCLoud中国云三强: 高可用架构实践云数据库UCloud云数据库（UDB）团队对UDB底层架构进行重构，对其性能和数据一致性等内核方面做了大量深入的工作。“高可用”英文翻译为“High Availability”，从字面上理解就是要做到服务full-time的持续可用。但老实说，要做到full-time是不现实的，因为能够影响系统服务可用性的因素实在太多了，除软件BUG、硬件故障外，还包括系统所依赖的一些如运营商提供的带宽等第三方服务，甚至还包括天灾人祸。因此，所谓的高可用意味着“更少的停服时间”，而工业界也有一套测量系统可用性的标准，即大家所熟知的SLA(Service Level A

2、greement),也就是几个9的可用性（如下表）：在工业应用场景中，例如做在线服务的各大互联网公司，号称7*24小时不间断服务，如果只是达到一个“9”的可用性，将会是一种什么样的灾难。然而，要做到5个“9”的可用性，就意味着全年只有一次服务宕机，而且必须在5分钟左右就恢复，其难度不言而喻，因此只是采用技术手段不足以做到，还需要有一整套完备严谨的工程管理防范措施、配套工具及工程运维人员等。云计算号称互联网公司的水和电，高可用犹如云服务商的生命线。因为云端成千上万个用户数据库实例所面临的问题会更加五花八门，所以云数据库作为该领域的一项重要服务，更是承受着不同维度的考验。下面将先介绍MySQL领域

3、的关键技术及适用场景，并在此基础上介绍和分享UDB的高可用方案。一、高可用数据库关键技术点数据库服务和很多工业服务在高可用技术方案是相通的，为了实现高可用，首先实现服务的”冗余”，即服务的集群化。如果服务有冗余备份，宕机后还有其它备份服务(热备和冷备)可以顶上，所以实现数据库服务的”冗余”也是高可用数据库的核心准则。不过，有了”冗余”备份后还不够，因为如果每次宕机都需要人工恢复切换至备份服务，那么恢复时间得不到保证，同时人为的故障恢复过程中可能会引入新的风险(人为事故)，从而降低了服务的可用性，因此必须还具备”自动故障转移”功能。数据库服务相比于其它系统的高可用，在上述两个关键技术点的实现上会

4、更加困难，因为传统RDMS对数据、事务的持久性与稳定性要求非高，因此也提高了对冗余数据的一致性要求和实现难度。二、高可用MySQL典型解决方案下图是Oracle官方对MySQL几种典型高可用方案的可用性总结，由于时间相对较早，并且随着近年来分布式一致性协议在工业界的实践和发展，MySQL高可用方案又有了全新的发展方向以及相对成熟的方案，下面将一并罗列与解析。（1）MySQL Replication 就是通过MySQL原生复制技术来实现数据的冗余，该方案也是较易实现和通用的方案，相关原理介绍不再详细赘述。其实现原理主要是通过2PC来实现本地BINLOG与本地数据的一致性，并在此基础上通过IO线程

5、和SQL线程来实现远端数据与本地数据同步，根据数据一致性程度不同，复制技术又可以分为异步复制、半同步复制以及同步复制。另外，在此冗余技术上，一般会搭配使用MySQLProxy、keepalived、MHA等第三方软件来实现自动容灾，该技术方案如果不做一定优化，可用性一般不到2个“9”。（2）MySQL Fabric 是Oracle官方提供的一种MySQL高可用方案，通过数据分片下的读写分离模式，该方案的可用性达到2个“9”。（3）分布式块设备复制(Distributed Relicated Block Deivce,DRBD)是一种基于软件、网络的块复制存储解决方案，主要用于对服务器之间的磁盘

6、、分区、逻辑卷等生成数据镜像。当用户将数据写入本地磁盘时，还会把数据发送到网络中另一台主机的磁盘上，使本地主机(主节点)与远程主机(备节点)数据实时同步，当本地主机出现问题时，远程主机上还保留着一份相同的数据，仍能继续使用，保证了数据安全，但该方案的缺点是IO性能影响严重，可用性不到3个“9”。（4）Solaris Clustering方案代表着另一种技术方向，即以共享存储为基础，实现数据库服务器和存储设备的解耦，其结果是数据库服务器之间的冗余与数据无关，数据冗余通过SAN共享储存或分布式存储系统来实现。当然，除此之外，Solaris Clustering还提供操作系统、硬件等各个层面的监控机

7、制。该方案的可用性达到接近4个“9”，但由于价格昂贵，实现代价大。（5）MySQL Cluster是官方提供的一个开源方案，其将MySQL的集群分为SQL节点和数据节点，数据节点通过一种内存中的存储引擎来实现自动sharding和复制。虽然该方案号称接近5个“9”的可用性，但缺点也很多，例如对内存消耗大、使用成本高、牺牲了过多SQL语言特性、配置复杂等。（6）Paxos 协议主要以多数派投票的方式来就分布式系统中某个值达成一致，该算法被业界认为是分布式一致性算法，包括其在内衍生出来的分布式一致性算法，如Raft，也在很多开源分布式系统得到应用。Paxos与MySQL相结合可以实现分布式MySQ

8、L数据库较终一致性，从而保证高可用，因而使用分布式算法来解决MySQL数据库一致性问题的方法也逐渐被用户所接受，一系列产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等，越来越多的被应用到生产环境。较近，Oracle官方推出MySQL Group Replication的GA，更使其在MySQL高可用领域成为一种民用技术，因此使用分布式协议和多副本来解决数据库一致性问题已经成为主流方向。但此类方案还处于初级阶段，不够成熟，同时分布式一致性协议由于网络开销的原因，在性能上还有待提高和优化。三、高可用数据库案例分享UDB为了实现云数据库

9、服务的高可用，基于半同步复制技术，UDB采用双主的热备架构，实现故障自动转移，并在此基础上实现了Proxy模块，该模块不仅负责数据业务的转发，同时还监控后端DB健康状况和双主数据一致性检测，实现在后端DB宕机但不影响数据一致性的情况下，完成数据业务切换。整个架构及容灾过程如下图：也许从架构上看很简单，一主一备的架构没有什么新意，但深入到细节中会发现仍有很多问题和难点，或者说这些问题都围绕“如何保证数据一致性”这个目标。普通异步复制对数据库性能影响较小，但主从数据一致性难以保证；强同步复制虽然保证了主从强一致，但可用性很差，因此UDB选择了折中方案半同步复制。不过，只是简单的使用半同步复制依然不

10、够，通过分析半同步复制的过程和原理，UCloud发现半同步复制会存在以下缺陷，在分析缺陷的同时也将介绍UDB的解决方案与策略：1、如何解决临界事务问题？什么是临界事务？临界事务就是在宕机那个时间点主库正在提交的事务，这个事务可能已经提交，可能已经fsync到磁盘，但却没有同步到从库中去。半同步复制对于临界事务是没法保证的，下图是MySQL5.7无损复制一次事务commit流程（UDB基于次复制技术做了优化）：如上图，UCloud对MySQL5.7版本中无损复制模式（默认模式下）的半同步复制主机commit做了细分，拆成7个可能crash的阶段，考虑到双机切换后可能会导致的数据丢失与数据一致性异

11、常，UCloud对每个阶段做了以下分析： 在阶段1、2、3发生了crash，由于主库重启后事务会回滚，binlog未发送到从库，所以不会发生异常； 在阶段4发生异常，由于主库进入了commit阶段，但是binlog尚未发送到从库，在主库重启后仍然会将这个事务发送到从机； 在阶段5、6、7发生异常，由于从库已经收到了binlog，只要主库重启后即可达到主库和备库数据一致的效果通过上述分析，无损复制模式下，只有在阶段4发生宕机会导致恢复后双主数据不一致，因为发生宕机时，该事务在此阶段并没有发送至从库。但主库已提交至binlog和redolog，如果此时业务切至从库，主库恢复后会继续将事务commi

12、t并同步到从库。不过，由于从库上已经有了新事务，因此很可能会与此事务产生冲突（如主键冲突），从而导致双主数据不一致。所以为了解决宕机时临界事务问题，UCloud通过内核层面在主库重启recovery阶段作了如下调整：有选择性的commit并复制到从库部分事务，回滚掉没有同步到原从库的事务及Truncate掉binlog中相应的event，整个过程如下图：如上图所示，主库恢复后，会向从库或者Proxy询问从本库同步过去的较后一条事务的binlog位置，并以此为基础回滚掉该binlog位置之后的临界事务。2、如何解决半同步退化问题？由于网络抖动以及从库硬件故障等问题会导致半同步退化为异步，如果在此

13、情况下主库发生宕机并发生切换，会导致数据丢失，对很多数据敏感业务（如金融）造成的后果将非常严重。因此，虽然当半同步复制退化时，整个集群是不可以容灾切换业务的，但如果主机宕机无法SSH登陆，又将怎样确定主从是否退化以及从库数据是否和主库一致？为了解决此问题，防止错误切换导致数据丢失，UDB通过在Proxy和MySQL之间以及主从之间增加链接通道，Proxy和MySQL会用专门线程通过此链接通道同步事务信息，如果主库发生宕机，从库可以在本地缓存和远端Proxy获取同步事务信息，并使用该事务信息作为从机是否可以切换的依据，如下图：同时，为了提高可用性，应对短时间网络抖动后造成双主长时间数据不一致的情

14、况，UDB在网络恢复后，会额外启动一个复制链路来追补落后的数据，而原先的半同步复制链路则继续用于复制实时事务。这样不仅可以提高复制数据效率，而且还避免了由于从库负载过高永远恢复半同步的风险。3、如何保证Proxy的高可用？通过前述问题以及UDB相应解决方案的分析，可以看出Proxy在整个架构中扮演着极其重要的角色，不仅负责数据转发，同时也为数据一致性和可用性提供保障。那么关注的另一个问题就出现了：如果Proxy宕机怎么办？为了解决Proxy高可用问题，UDB对Proxy模块也采用了“一主一备”模式，如下图：当图中左路主Proxy宕机后，ProxyMaster模块会触发容灾处理过程，此时ProxyMaster会将虚拟IP重新绑定至Proxy（backup）并自动启动，启动后Proxy（backup）会重