一文了解数据库高可用容灾方案的设计与实现

一个系统可能包含不少模块，如数据库、前端、缓存、搜索、消息队列等，每一个模块都须要作到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用的实现可能更加复杂，对用户的服务可用，不只仅是能访问，还须要有正确性保证，所以讨论数据库的高可用方案时，在容灾以外，还要同时考虑方案中数据一致性问题。

本文将经过介绍一些业界主流的数据库高可用架构、每种方案的特性和优缺点，以及数据库高可用架构的自动化运维实现，讲讲数据库高可用容灾方案设计与实现，但愿抛砖引玉，和你们一块儿讨论。

1、高可用数据库概述

什么是高可用数据库？

高可用数据库是由一系列数据库构成的整体系统，在任什么时候刻，至少有一个节点能够接受用户的请求并提供数据库服务。大多数数据库架构中，有一个主节点处理主要请求，还有若干备用节点用于容灾切换，当主节点不能提供服务时，备用节点成为主节点继续提供服务，用以保证整个系统的可用和稳定。

高可用数据库有不少优势：

第一，方便读写分离。数据库请求当中，通常读操做的请求次数远大于写操做，高可用数据库能够经过将写操做放在主数据库节点上进行，将读操做分担到若干从库上，来提高读操做吞吐量，进而提高读写效率； 第二，变动不停服。当整个高可用数据库架构或者主节点升级时，可让高可用数据库先进行主库切换，让备用节点替换原主节点提供数据库服务，当主节点升级完毕后，再将主从库服务切换回来，这样能有效避免系统升级或变动时对用户服务质量产生影响； 第三，备份不影响服务性能。高可用数据库架构包含多个从库，在不影响主节点服务性能的状况下，能很是方便地实现数据的容灾备份。

通常，高可用数据库地架构设计时，也须要考虑三个问题：

第一，如何同步各数据库之间的节点数据？同步须要保证切换后的数据库是最新数据，以及在切换过程当中数据不会丢失，同时还要考虑同步过程对主库和备库的影响。 第二，高可用数据库的容灾切换如何进行？架构不一样容灾切换的复杂度也不同，且切换之后须要保证主、从库数据的一致性，这可能须要开发者在设计之初就尽可能优化和简化容灾切换逻辑。 第三，如何提升高可用的运维效率？

2、业界典型高可用数据库架构

按照数据同步方式，咱们能够将业界主流的高可用架构划分红四种：第一种，共享存储方案；第二种，操做系统实时数据块复制；第三种，数据库级别的主从复制；第四种，高可用数据库集群。每一种数据同步方式能够衍生出不一样的架构。

方案一：共享存储

共享存储指若干DB服务使用同一份存储，一个为主DB，其余的为备用DB，若主服务崩溃，则系统启动备用DB，成为新的主DB，继续提供服务。通常共享存储采用比较多的是SAN/NAS方案。

这种方案的优势是没有数据同步的问题，但也有一些限制，如对于共享存储的实时性和网络性能有较高要求。由于共享存储通常是经过网络来访问存储当中的数据，在网络性能较差的状况下，数据库的性能也没法达到使人满意的效果。不过，随着硬件性能的不断提高，将计算存储分离、和DB深度结合的共享存储亦是高可用数据库将来发展的趋势之一。

方案二：操做系统实时数据块复制

这个方案的典型场景是DRBD，能够把它理解为远程的RAID1，以下图所示，左侧数据库写入数据之后当即同步到右侧的存储设备当中。若是左边数据库崩溃，系统能够直接激活右边的数据库存储设备，启动新的数据库服务，实现容灾切换。

这个方案一样有一些问题，如系统只能有一个数据副本提供服务，没法实现读写分离；另外，若是系统崩溃，主库进程中断，容灾切换后须要在挂掉的数据库上作数据库崩溃恢复，系统须要的容灾恢复时间较长。

方案三：数据库主从复制

这种方案我认为是最经典的数据同步模式，系统采用一个主库和多个从库方式，其实现原理主要是基于日志的主从复制，主库操做以日志的形式发送给各个从库，从库接收到日志后进行数据备份。这种方式的好处是一个主库能够链接多个从库，能很方便地实现读写分离，同时，由于每一个备库都在运行中，因此备库里面的数据基本上都是热数据，容灾切换也很是快。

不过，这个方案也并不是天衣无缝，如容灾切换时，从库必定要同步完最新数据之后才能升级为主库，不然极有可能发生数据丢失的状况。针对传统主从架构的一些问题，业界也逐渐研发出对应的改进技术。

改进技术一：双主架构

问题：经典主从架构里面，原主库崩溃恢复的过程当中，新的数据没法及时同步到该数据库当中，原主库恢复后，须要从新设置为从库，并将容灾过程当中的数据从新同步进行。

改进措施：为了保证容灾后的数据一致性，业界对这种架构作了一些改进，其中一种改进措施就叫双主架构，以下图所示，双主架构通常会选择两个DB作一对主库，这两个DB之间互相为对方的从库，不管往哪一个DB写入数据，另外一个都会自动同步。容灾时系统只须要把流量从左边切换到右边，容灾后数据同步依旧自动进行，这样，就保证了容灾后原主库的数据一致性。

改进技术二：日志自动寻址

问题：容灾备份时，当某一从库提高为主库后，其余备库须要自动定位新主库的日志同步点，同步新主库的日志。早期数据库日志中，MySQL是经过文件名加上文件的偏移量进行寻址，所以，主库的自动定位并很差实现。

改进措施：为了解决此问题，MySQL提供了一种叫作GTID的全局事务标志技术，一个事务对应一个ID，全部的日志都带有惟一的标识符，主从库切换后，其他从库只要根据新主库的日志ID，就能够辨别新的日志同步点，而后根据这个日志同步数据，这对于搭建一主库多从库的架构来讲寻址很是便捷。

改进技术三：异步复制改进

问题：默认状况下，MySQL的复制是异步的，主库将新生成的日志发送给各从库后，无需等待从库的ack回复(从库将接收到的日志写进relay log后，才会回复ack)，直接就认为此次DDL/DML成功了。但在极端状况下，如主库刚提交日志，其余从库尚未接收到相关日志时，数据库发生故障，此时，该日志的内容就会所有丢失。

改进措施：半同步复制机制。半同步复制是指主库在将新生成的日志发送给各从库前，需发送日志到一个(默认)从库，等待从库返回ack信息后，主库再提交日志发送给各从库,这就防止了上述状况下的数据丢失。半同步复制是一种提高数据一致性的有效方式，也是比较关键的技术。

方案四：数据库高可用集群

前面三种方案主要是经过日志的复制模式实现高可用，第四种方案则是基于一致性算法来作数据的同步，数据库提供多节点一致性同步机制，利用该机制构建多节点同步集群。这种方式比较经典的案例包括MGR（MySQL Group Replication）和Galera等，最近业内也有一些相似的尝试，如使用一致性协议算法，自研高可用数据库的架构等。

以上示意图有五个节点，他们之间是构建成了一个一致性的同步集群，客户端能够读写其中的任何一个节点，任意一节点写入，其余节点都可以将数据进行同步，所以，理论上每一个节点均可以进行读写操做。这种方式的容灾实现也比较简单，假设第二个节点出现故障，系统只须要断开客户端对第二个节点的访问路径，其余节点照常访问就能够了，这也是业界近年来比较流行的高可用集群方案。

UCloud高可用数据库解决方案UDB

UCloud对比了业内的各解决方案的优劣点，综合了原生MySQL兼容，不一样版本、不一样应用场景的覆盖等多种因素，最终选择采用基于数据库主从复制的方式实现高可用架构，并在原架构基础上，使用双主架构、半同步复制、采用GTID等措施进行了系列优化，保证数据一致性的同时，实现日志的自动寻址。

如上图所示，最底层为数据层，使用了双主架构，主库与备主库之间经过半同步的方式实现数据同步，整个数据层是双主架构+半同步架构的模式。中间层有一个代理服务器Proxy，Proxy将流量导入到双主数据库的主节点，架构使用了GTID的模式，方便从库自动寻址。

系统的容灾切换也很是简单，数据库崩溃前，Proxy将流量导到主DB上，发生容灾之后，只须要把Proxy从左边Master导到右边的Slave，便可快速完成切换。

3、高可用数据库的自动化运维

自动化运维的重点方向

自动化运维是高可用数据库中的难点，由于企业业务不必定只有一个数据库，可能须要同时管理十几个甚至上百个数据库，若是每个数据库都配置一个高可用数据库架构，系统则须要保证其中任何一个发生问题之后均可以进行容灾，这无疑给运维带来了极大挑战。

那么，如何同时管理大量高可用数据库，让他们均可以进行容灾呢？这里有一些自动化运维方向的思路：一、容灾切换自动化；二、高可用数据库运行情况监控；三、健康情况自动检查和问题修复。

一、容灾切换自动化。要实现容灾切换的自动化，首先须要考虑两个问题：

第一，怎样准确判断须要容灾。这是实现自动容灾的基础和前提，它须要结合实际状况讨论和判断。如发生网络波动时，可能有一段时间发现没法连上主库，实际上几秒钟之后整个业务系统又恢复了，若是这时候数据库作容灾的话代价比较大，且容灾后还可能会有额外的风险。因此须要在前期准确判断是否须要容灾，并保证在最须要容灾的时候及时容灾； 第二，容灾切换时，备库数据尽可能和主库数据保持一致，不然，就会带来数据丢失的问题。

针对上述问题，MySQL已经有比较经常使用方案供参考，老牌的如MHA，还有一种比较新的方案叫Orchestrator，若是你们本身搭建数据库，能够考虑采用这两种方案。

二、健康情况自动检查。健康情况检查须要经过自动监控搭配告警来作，高可用容灾中，最关心的仍是高可用数据库的主库和备库数据是否一致，通常状况，致使主从库数据不一致的主要是两点：

第一，复制有没有正常进行，如发送日志时主库与备库之间的链接忽然断掉，这时候须要系统时常扫描主备库是否异常； 第二，主从延时，若是主从之间的数据延迟较大，那么切换数据库时也会比较麻烦，这方面也能够考虑使用业内比较经常使用的监控模块如Prometheus等工具按期采集，发现异常情况后及时调整。

第三，异常状况自适应调整。以主从延迟为例，通常来讲多是CPU的问题或者IO的问题等，若是是IO的问题，一种办法是将IO调高，这是一种比较好的解决方案，若是IO调高之后发现仍是没法下降延时，能够在从库把日志的持久化等级暂时性调低。固然，若是主从之间延迟过大，彻底没法调整为正常水平，这时候就要考虑经过一些手段重作从库。

UDB：海量高可用数据库自动化运维

UDB拥有海量的高可用数据库，在自动化运维和管理方面，UDB采用的是高可用容灾集中式自动化管理的方式，经过自研的自动容灾逻辑，进行大规模、高并发的DB自动化容灾。同时，UDB的运维体系还能够作到自动化的问题探测以及问题修复，如自动拉起DB、恢复服务，自动恢复数据同步，自适应流量控制等。此外，UDB还会配合一些高效运维工具和巡检工具作更深层次的问题的发现和解决。

在UDB高可用运维当中，有几点经验能够跟你们分享：

第一，平常须要作例行巡检，保证高可用数据库的健康。主从延时是致使高可用数据库没法容灾的关键缘由之一，这一点必定要在平常运维工做中重视起来； 第二，按期容灾演练颇有必要。容灾演练就是在平台上跑本身的容灾逻辑，咱们须要在不一样场景下作切换，看数据有没有丢失、是否保持了数据的一致性等等，由于线上环境很是复杂，可能会有各类莫名其妙的问题致使切换逻辑在发生切换之后结果不一致，因此要经过按期演练把各类可能性降到最低； 第三，高可用切换须要记录日志，而且在切换失败的时候立刻告警。切换日志能够作过后复盘分析，看这个DB是何时崩溃作的容灾。进入告警后能够保证第一时间介入并解决，缩短整个DB崩溃对用户的影响时间。

4、总结

高可用架构是数据库运行稳定必不可少的一部分，设计架构时要考虑诸多问题，如数据是否同步、高可用自动切换、自动化运维等等。前面讲解了四种基于数据库同步的数据库高可用架构，若是是在云环境下，推荐使用UDB云数据库这样的产品一键完成上述配置，帮助减轻业务的运维压力。

做者介绍

丁顺，UCloud资深存储研发工程师，在云产品、大规模海量存储方面具备丰富的经验，擅长于分布式系统、面向服务、容器化、高可用等方面的架构和软件设计。

想要获取更多技术和活动资讯，可微信关注“UCloud技术公告牌”微信公众号；或搜索微信ID：ucloud_tech进行关注。 您也能够添加运营小妹微信：Likekids，欢迎交流咨询更多技术问题！9大技术交流群，等你加入！