高可用架构实云数据库

高可用架构实践云数据库

UCloud云数据库（UDB）团队对UDB底层架构进行重构，对其性能和数据一致性等内核方面做了大量深入的工作。

“高可用”英文翻译为“High Availability”，从字面上理解就是要做到服务full-time的持续可用。但老实说，要做到full-time是不现实的，因为能够影响系统服务可用性的因素实在太多了，除软件BUG、硬件故障外，还包括系统所依赖的一些如运营商提供的带宽等第三方服务，，甚至还包括天灾人祸。因此，所谓的高可用意味着“更少的停服时间”，而工业界也有一套测量系统可用性的标准，即大家所熟知的SLA(Service Level Agreement),也就是几个9的可用性（如下表）：

在工业应用场景中，例如做在线服务的各大互联网公司，号称7*24小时不间断服务，如果只是达到一个“9”的可用性，将会是一种什么样的灾难。然而，要做到5个“9”的可用性，就意味着全年只有一次服务宕机，而且必须在5分钟左右就恢复，其难度不言而喻，因此只是采用技术手段不足以做到，还需要有一整套完备严谨的工程管理防范措施、配套工具及工程运维人员等。

云计算号称互联网公司的水和电，高可用犹如云服务商的生命线。因为云端成千上万个用户数据库实例所面临的问题会更加五花八门，所以云数据库作为该领域的一项重要服务，更是承受着不同维度的考验。

下面将先介绍MySQL领域的关键技术及适用场景，并在此基础上介绍和分享UDB的高可用方案。

数据库服务和很多工业服务在高可用技术方案是相通的，为了实现高可用，首先实现服务的”冗余”，即服务的集群化。如果服务有冗余备份，宕机后还有其它备份服务(热备和冷备)可以顶上，所以实现数据库服务的”冗余”也是高可用数据库的核心准则。

不过，有了”冗余”备份后还不够，因为如果每次宕机都需要人工恢复切换至备份服务，那么恢复时间得不到保证，同时人为的故障恢复过程中可能会引入新的风险(人为事故)，从而降低了服务的可用性，因此必须还具备”自动故障转移”功能。

数据库服务相比于其它系统的高可用，在上述两个关键技术点的实现上会更加困难，因为传统RDMS对数据、事务的持久性与稳定性要求非高，因此也提高了对冗余数据的一致性要求和实现难度。

下图是Oracle官方对MySQL几种典型高可用方案的可用性总结，由于时间相对较早，并且随着近年来分布式一致性协议在工业界的实践和发展，MySQL高可用方案又有了全新的发展方向以及相对成熟的方案，下面将一并罗列与解析。

（1）MySQL Replication 就是通过MySQL原生复制技术来实现数据的冗余，该方案也是较易实现和通用的方案，相关原理介绍不再详细赘述。其实现原理主要是通过2PC来实现本地BINLOG与本地数据的一致性，并在此基础上通过IO 线程和SQL线程来实现远端数据与本地数据同步，根据数据一致性程度不同，复制技术又可以分为异步复制、半同步复制以及同步复制。另外，在此冗余技术上，一般会搭配使用MySQLProxy、keepalived、MHA等第三方软件来实现自动容灾，该技术方案如果不做一定优化，可用性一般不到2个“9”。（2）MySQL Fabric 是Oracle官方提供的一种MySQL高可用方案，通过数据分片下的读写分离模式，该方案的可用性达到2个“9”。

（3）分布式块设备复制(Distributed Relicated Block Deivce,DRBD)是一种基于软件、网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等生成数据镜像。当用户将数据写入本地磁盘时，还会把数据发送到网络中另一台主机的磁盘上，使本地主机(主节点)与远程主机(备节点)数据实时同步，当本地主机出现问题时，远程主机上还保留着一份相同的数据，仍能继续使用，保证了数据安全，但该方案的缺点是IO性能影响严重，可用性不到3个“9”。

（4）Solaris Clustering方案代表着另一种技术方向，即以共享存储为基础，实现数据库服务器和存储设备的解耦，其结果是数据库服务器之间的冗余与数据无关，数据冗余通过SAN共享储存或分布式存储系统来实现。当然，除此之外，Solaris Clustering还提供操作系统、硬件等各个层面的监控机制。该方案的可用性达到接近4个“9”，但由于价格昂贵，实现代价大。

（5）MySQL Cluster是官方提供的一个开源方案，其将MySQL的集群分为SQL 节点和数据节点，数据节点通过一种内存中的存储引擎来实现自动sharding和复制。虽然该方案号称接近5个“9”的可用性，但缺点也很多，例如对内存消耗大、使用成本高、牺牲了过多SQL语言特性、配置复杂等。

（6）Paxos 协议主要以多数派投票的方式来就分布式系统中某个值达成一致，该算法被业界认为是分布式一致性算法，包括其在内衍生出来的分布式一致性算法，如Raft，也在很多开源分布式系统得到应用。

Paxos与MySQL相结合可以实现分布式MySQL数据库较终一致性，从而保证高可用，因而使用分布式算法来解决MySQL数据库一致性问题的方法也逐渐被用户所接受，一系列产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等，越来越多的被应用到生产环境。较近，Oracle官方推出MySQL Group Replication的GA，更使其在MySQL高可用领域成为一种民用技术，因此使用分布式协议和多副本来解决数据库一致性问题已经成为主流方向。

但此类方案还处于初级阶段，不够成熟，同时分布式一致性协议由于网络开销的原因，在性能上还有待提高和优化。

为了实现云数据库服务的高可用，基于半同步复制技术，UDB采用双主的热备架构，实现故障自动转移，并在此基础上实现了Proxy模块，该模块不仅负责数据业务的转发，同时还监控后端DB健康状况和双主数据一致性检测，实现在后端DB宕机但不影响数据一致性的情况下，完成数据业务切换。整个架构及容灾过程如下图：

也许从架构上看很简单，一主一备的架构没有什么新意，但深入到细节中会发现仍有很多问题和难点，或者说这些问题都围绕“如何保证数据一致性”这个目标。普通异步复制对数据库性能影响较小，但主从数据一致性难以保证；强同步复制虽然保证了主从强一致，但可用性很差，因此UDB选择了折中方案——半同步复制。不过，只是简单的使用半同步复制依然不够，通过分析半同步复制的过程和原理，UCloud发现半同步复制会存在以下缺陷，在分析缺陷的同时也将介绍UDB的解决方案与策略：

1、如何解决临界事务问题？

什么是临界事务？临界事务就是在宕机那个时间点主库正在提交的事务，这个事务可能已经提交，可能已经fsync到磁盘，但却没有同步到从库中去。半同步复