前言
对数据库服务而言，实现高可用会更加复杂，不仅能访问，还需要保证正确性。因此在容灾之外，数据库高可用方案还要同时考虑数据一致性问题。本文将介绍部分业界主流数据库高可用架构的特性、优缺点及其自动化运维，进一步阐释数据库高可用容灾方案的设计与实现。
什么是高可用数据库？
高可用数据库是由一系列数据库构成的总体系统，在任何时刻，至少有一个节点可以接受用户的请求并提供数据库服务。
（图：什么是高可用数据库）
高可用数据库的优点：
第一，方便读写分离。
高可用数据库可以通过将写操作放在主数据库节点上进行，将读操作分担到若干从库上，来提升读操作吞吐量，进而提升读写效率。
第二，变更不停服。
当整个高可用数据库架构或主节点升级时，可以让高可用数据库先进行主库切换，备用节点替换原主节点提供数据库服务，当主节点升级完毕后，再将主从库服务切换回来，这样能有效避免系统升级或变更时对用户服务质量产生影响。
第三，备份不影响服务性能。
高可用数据库架构包含多个从库，在不影响主节点服务性能的情况下，能非常方便地实现数据的容灾备份。
通常，在进行高可用数据库架构设计时，需要考虑三个问题：
如何同步各数据库之间的节点数据？同步需要保证切换后的数据库是最新数据，以及在切换过程中数据不会丢失，同时还要考虑同步过程对主库和备库的影响。高可用数据库的容灾切换如何进行？架构不同，容灾切换的复杂度也不一样，且切换以后需要保证主、从库数据的一致性，这可能需要开发者在设计之初就尽量优化和简化容灾切换逻辑。如何提高高可用的运维效率？
典型高可用数据库架构
按照数据同步方式，可以将业界主流高可用架构分为四种：共享存储方案、操作系统实时数据块复制、数据库级别的主从复制、高可用数据库集群。每一种数据同步方式可以衍生出不同架构。
方案一：共享存储
共享存储指若干DB服务使用同一份存储，一个为主DB，其它为备用DB。若主服务崩溃，则系统启动备用DB，成为新的主DB，继续提供服务。一般共享存储采用比较多的是SAN/NAS方案。
（图：共享存储）
虽然该方案的优点是没有数据同步的问题，但也有一些限制，如对于共享存储的实时性和网络性能有较高要求。而随着硬件性能的不断提升，将计算存储分离、和DB深度结合的共享存储亦是高可用数据库未来发展趋势之一。
方案二：操作系统实时数据块复制
这一方案的典型场景是DRBD，可以理解为远程的RAID1。如下图所示，左侧数据库写入数据以后，立即同步到右侧的存储设备当中。如果左边数据库崩溃，系统可以直接激活右边的数据库存储设备，启动新的数据库服务，实现容灾切换。
（图：操作系统实时数据块复制）
这个方案的缺点也比较明显，如系统只能有一个数据副本提供服务，无法实现读写分离；另外，如果系统崩溃，主库进程中断，容灾切换后需要在挂掉的数据库上做数据库崩溃恢复，系统需要的容灾恢复时间较长。
方案三：数据库主从复制
这种方案是最经典的数据同步模式，系统采用一个主库和多个从库方式，实现原理主要是基于日志的主从复制，主库操作以日志的形式发送给各个从库，从库接收到日志后进行数据备份。
优点是一个主库可以连接多个从库，能很方便地实现读写分离，同时因为每个备库都在运行中，所以备库里的数据基本都是热数据，容灾切换也非常快。
（图：数据库主从复制）
不过，这个方案也并非完美无缺，如容灾切换时，从库一定要同步完最新数据以后才能升级为主库，否则极有可能导致数据丢失。针对这些问题，业界也正在研发对应的改进技术。
改进技术一：双主架构
为了保证容灾后的数据一致性，业界对这种架构做了改进，其中一种就是双主架构。如下图所示，双主架构一般会选择两个DB做一对主库，这两个DB互为对方的从库，无论往哪个DB写入数据，另一个都会自动同步。容灾时，系统只需把流量从左边切换到右边，容灾后数据同步依旧自动进行，这样就保证了容灾后原主库的数据一致性。
（图：主从复制-双主架构）
改进技术二：日志自动寻址
早期数据库日志中，MySQL是通过文件名加上文件偏移量进行寻址，因此主库的自动定位并不好实现。为了解决此问题，MySQL提供了一种叫做GTID的全局事务标志技术，一个事务对应一个ID，所有日志都带有唯一的标识符。主从库切换后，其余从库只要根据新主库的日志ID，就可以辨别新的日志同步点，然后根据这个日志同步数据，这对于搭建一主库多从库的架构来说寻址非常便捷。
（图：主从复制-改进技术）
改进技术三：异步复制改进
默认情况下，MySQL的复制为异步。但在极端情况下，如主库刚提交日志，其它从库还没有接收到相关日志时，数据库发生故障，此时该日志的内容就会全部丢失，而采用半同步复制机制可有效解决此问题。半同步复制是指主库在将新生成的日志发送给各从库前，需发送日志到一个(默认)从库，等待从库返回ack信息后，主库再提交日志发送给各从库。半同步复制是一种提升数据一致性的有效方式，也是比较关键的技术。
方案四：数据库高可用集群
前三种方案主要通过日志的复制模式实现高可用，第四种方案则基于一致性算法来做数据同步，数据库提供多节点一致性同步机制，利用该机制构建多节点同步集群。这种方式比较经典的案例包括MGR（MySQLGroupReplication）和Galera等，近期业内也有一些类似尝试，如使用一致性协议算法，自研高可用数据库架构等。
（图：数据库高可用集群）
如上图所示，五个节点构建成了一个一致性的同步集群，客户端可以读写其中的任一节点，其它节点都能进行数据同步，因此理论上每个节点都可以进行读写操作。这种方式的容灾实现也比较简单，假设第二个节点出现故障，系统只需要断开客户端对第二个节点的访问路径，其它节点照常访问即可，这也是业界近年来比较流行的高可用集群方案。
UCloud高可用数据库解决方案UDB
UCloud对比了业内各解决方案的优劣，综合了原生MySQL兼容以及不同版本、应用场景的覆盖等多种因素，最终选择采用基于数据库主从复制的方式实现高可用架构，并在原架构基础上采用双主架构、半同步复制、GTID等措施进行了系列优化，既保证数据一致性，又实现日志自动寻址。
（图：案例-UDBMySQL高可用实例架构）
如上图所示，最底层为数据层，使用了双主架构，主库与备主库之间通过半同步的方式实现数据同步；中间层有一个代理服务器Proxy将流量导入到双主数据库的主节点，使用了GTID的模式，方便从库自动寻址。
系统的容灾切换也非常简单，数据库崩溃前，Proxy将流量导入主DB，发生容灾以后，只需把Proxy从左边Master导到右边Slave，即可快速完成切换。
（图：UDB容灾切换示意图）
高可用数据库的自动化运维
自动化运维是高可用数据库中的难点，因为企业业务不一定只有一个数据库，可能需要同时管理十几个甚至上百个数据库，如果每一个数据库都配置一个高可用数据库架构，系统则要保证其中任何一个发生问题以后都可以进行容灾，这无疑给运维带来了极大挑战。
那么，如何同时管理大量高可用数据库，使其都可进行容灾？目前自动化运维方向的思路包括容灾切换自动化、健康状况自动检查和问题修复、高可用数据库运行状况监控等。
1、要实现容灾切换自动化，首先考虑两个问题：一是怎样准确判断需要容灾，这是实现自动容灾的基础和前提；二是容灾切换时，备库数据尽量和主库数据保持一致，否则就容易带来数据丢失问题。
（图：容灾切换自动化）
针对上述问题，MySQL已经有比较常用的方案，如MHA，还有一种比较新的方案叫Orchestrator，如果自行搭建数据库，可以考虑采用这两种方案。
2、健康状况自动检查需要通过自动监控搭配告警来做，在高可用容灾中，最关键的还是高可用数据库的主库和备库数据是否一致。通常，导致主从库数据不一致的主要原因有两方面：第一，复制有没有正常进行，如发送日志时主库与备库之间的连接突然断掉，这时需要系统扫描主备库是否异常；第二，主从延时，如果主从之间的数据延迟较大，那么切换数据库时也会比较麻烦，可以考虑使用业内比较常用的监控模块，如Prometheus等工具定期采集，发现异常状况后及时调整。
（图：健康状况自动检查）
3、异常情况自适应调整，以主从延迟为例，可能是CPU或者IO的问题，如果是IO，一种办法是将IO调高，这是一种比较好的解决方案，如果IO调高以后还是无法降低延时，可以在从库把日志的持久化等级暂时性调低。当然，如果主从之间延迟过大，完全无法调整为正常水平，这时候就要考虑通过一些手段重做从库。
UDB：海量高可用数据库自动化运维
UDB拥有海量的高可用数据库，在自动化运维和管理方面，UDB采用的是高可用容灾集中式自动化管理方式，通过自研的自动容灾逻辑，进行大规模、高并发的DB自动化容灾。同时，UDB的运维体系还可以做到自动化问题探测以及修复，如自动拉起DB恢复服务、自动恢复数据同步、自适应流量控制等。此外，UDB还会配合一些高效运维工具和巡检工具做更深层次的问题发现和解决。
（图：海量高可用数据库自动化运维）
UDB高可用运维中的几点经验：
第一，日常需要做例行巡检，保证高可用数据库的健康。主从延时是导致高可用数据库无法容灾的关键原因之一，因此一定要在日常运维工作中重视起来。
第二，定期容灾演练很有必要。容灾演练就是在平台上跑容灾逻辑，需要在不同场景下做切换，看数据有没有丢失、是否保持了数据一致性等，因为线上环境非常复杂，可能会有各种莫名其妙的问题导致切换逻辑在发生切换以后结果不一致，所以要通过定期演练把各种可能性降到最低。
第三，高可用切换需要记录日志，并且在切换失败时马上告警。切换日志可以做事后复盘分析，看DB是什么时间崩溃做的容灾。进入告警后可以保证第一时间介入并解决，减小整个DB崩溃对用户的影响。
（图：高可用运维经验）
总结
高可用架构是数据库运行稳定必不可少的一部分，设计架构时要考虑诸多问题，如数据是否同步、高可用自动切换、自动化运维等。如果是在云环境下，推荐使用UDB云数据库来一键完成配置，降低业务运维压力。
—End—