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