一个系统可能包含很多模块，如数据库、前端、缓存、搜索、消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用的实现可能更加复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，在容灾之外，还要同时考虑方案中数据一致性问题。
一、高可用数据库概述
1. 什么是高可用数据库?
高可用数据库是由一系列数据库构成的总体系统，在任何时刻，至少有一个节点可以接受用户的请求并提供数据库服务。大多数数据库架构中，有一个主节点处理主要请求，还有若干备用节点用于容灾切换，当主节点不能提供服务时，备用节点成为主节点继续提供服务，用以保证整个系统的可用和稳定。
2. 高可用数据库有很多优点：
- 第一，方便读写分离。数据库请求当中，一般读操作的请求次数远大于写操作，高可用数据库可以通过将写操作放在主数据库节点上进行，将读操作分担到若干从库上，来提升读操作吞吐量，进而提升读写效率;
- 第二，变更不停服。当整个高可用数据库架构或者主节点升级时，可以让高可用数据库先进行主库切换，让备用节点替换原主节点提供数据库服务，当主节点升级完毕后，再将主从库服务切换回来，这样能有效避免系统升级或变更时对用户服务质量产生影响;
- 第三，备份不影响服务性能。高可用数据库架构包含多个从库，在不影响主节点服务性能的情况下，能非常方便地实现数据的容灾备份。
3. 高可用数据库设计
一般，高可用数据库架构设计时，也需要考虑三个问题：
- 第一，如何同步各数据库之间的节点数据?同步需要保证切换后的数据库是最新数据，以及在切换过程中数据不会丢失，同时还要考虑同步过程对主库和备库的影响。
- 第二，高可用数据库的容灾切换如何进行?架构不同容灾切换的复杂度也不一样，且切换以后需要保证主、从库数据的一致性，这可能需要开发者在设计之初就尽量优化和简化容灾切换逻辑。
- 第三，如何提高高可用的运维效率?
二、业界高可用架构方案
业界典型的高可用架构可以划分为四种：
1. 共享存储。
共享存储是指若干DB服务使用同一份存储，一个主DB，其他的为备用DB，若主服务崩溃，则系统启动备用DB，成为新的主DB，继续提供服务。一般共享存储采用比较多的是SAN/NAS方案，这种方案的优点是没有数据同步的问题，缺点是对网络性能要求比较高。
2. 操作系统实时数据块复制。
这种方案的典型场景是DRBD。如下图所示，左边数据库写入数据以后立即同步到右边的存储设备当中。如果左边数据库崩溃，系统直接将右边的数据库存储设备激活，完成数据库的容灾切换。这个方案同样有一些问题，如系统只能有一个数据副本提供服务，无法实现读写分离;另外，系统崩溃后需要的容灾恢复时间较长。
3. 数据库主从复制。
这种方案是较经典的数据同步模式，系统采用一个主库和多个从库，主库同步数据库日志到各个从库，从库各自回放日志。它的好处是一个主库可以连接多个从库，能很方便地实现读写分离，同时，因为每个备库都在启动当中，所以备库当中的数据基本上都是热数据，容灾切换也非常快。
4. 数据库高可用集群。
前面三种是通过复制日志的模式实现高可用，第四种方案是基于一致性算法来做数据同步。数据库提供一种多节点的一致性同步机制，然后利用该机制构建多节点同步集群，这是业界近年来比较流行的高可用集群的方案。
三、数据库容灾规划
一般数据容灾会实现两地两个数据中心，1 主 2 从数据容灾架构，并建立数据库日常数据灾备体系。但为了提高 IT 服务管理水平，企业用户需要构建新一代多活系统规划设计总体目标：实现数据 0 丢失，同时满足在任何灾难情况下实现 30 分钟恢复对外数据服务。主要结合当前主流容灾、灾备技术与企业未来 5 年内，多地数据中心建设进行整体容灾与灾备建设规划、容灾演练、自动化监控与管理规划。
1. 服务连续性规划
衡量连续性水平主要指标是恢复时间目标(RTO)和恢复点目标(RPO)。
- 恢复时间目标(RTO)：企业可容许服务中断的时长;
- 恢复点目标(RPO)：指当服务恢复后，恢复得来的数据所对应时间点。
结合当前 XXX 实际现状目前规划 2 个级别连续性等级规划：
2. 技术选型规划
3. 自动化管理平台规划
通过数据库自动化管理平台中容灾&灾备监控管理中心可以实现对多个数据中心全局数据容灾、数据灾备的情况进行整体拓扑监控与管理。并且
为了保证数据容灾、数据灾备有效性对数据同步延迟、数据传输流量根据数据中心的链路带宽分配情况定制对应的告警监控。
自动化运维是高可用数据库中的难点，因为企业业务不一定只有一个数据库，可能需要同时管理十几个甚至上百个数据库，如果每一个数据库都配置一个高可用数据库架构，系统则需要保证其中任何一个发生问题以后都可以进行容灾，这无疑给运维带来了极大挑战。
下面提供几个自动化运维方向的思路：
(1) 容灾切换自动化。
要实现容灾切换的自动化，首先需要考虑两个问题：
- 第一，怎样准确判断需要容灾。这是实现自动容灾的基础和前提，它需要结合实际情况讨论和判断。如发生网络波动时，可能有一段时间发现无法连上主库，实际上几秒钟以后整个业务系统又恢复了，如果这时候数据库做容灾的话代价比较大，且容灾后还可能会有额外的风险。所以需要在前期准确判断是否需要容灾，并保证在最需要容灾的时候及时容灾;
- 第二，容灾切换时，备库数据尽量和主库数据保持一致，否则，就会带来数据丢失的问题。
针对上述问题，MySQL已经有比较常用方案供参考，老牌的如MHA，还有一种比较新的方案叫Orchestrator，如果大家自己搭建数据库，可以考虑采用这两种方案。
(2) 健康状况自动检查。
健康状况检查需要通过自动监控搭配告警来做，高可用容灾中，最关心的还是高可用数据库的主库和备库数据是否一致，一般情况，导致主从库数据不一致的主要是两点：
- 第一，复制有没有正常进行，如发送日志时主库与备库之间的连接突然断掉，这时候需要系统时常扫描主备库是否异常;
- 第二，主从延时，如果主从之间的数据延迟较大，那么切换数据库时也会比较麻烦，这方面也可以考虑使用业内比较常用的监控模块如Prometheus等工具定期采集，发现异常状况后及时调整。
- 第三，异常情况自适应调整。以主从延迟为例，一般来说可能是CPU的问题或者IO的问题等，如果是IO的问题，一种办法是将IO调高，这是一种比较好的解决方案，如果IO调高以后发现还是无法降低延时，可以在从库把日志的持久化等级暂时性调低。当然，如果主从之间延迟过大，完全无法调整为正常水平，这时候就要考虑通过一些手段重做从库。
4. 数据库容灾&灾备演练规划
规划通过使用数据库自动化管理平台中的“一键容灾切换”-演练切换、“一键灾备恢复”-数据库恢复模块进行恢复演练操作。
定期容灾演练很有必要。容灾演练就是在平台上跑自己的容灾逻辑，我们需要在不同场景下做切换，看数据有没有丢失、是否保持了数据的一致性等等，因为线上环境非常复杂，可能会有各种莫名其妙的问题导致切换逻辑在发生切换以后结果不一致，所以要通过定期演练把各种可能性降到最低。
总结
高可用架构是数据库运行稳定必不可少的一部分，设计架构时要考虑诸多问题，如数据是否同步、高可用自动切换、自动化运维等等。
