2024【崖山论”见“】已强势回归！即日起，将不定期把 Meetup 中 YashanDB 技术专家的精彩分享整理成文章，方便大家学习回顾。今天带来第一篇主备高可用技术文章。

作者介绍：

背景

数据库高可用（High Availability，HA）是指在系统遇到故障或异常情况时，能够自动快速地恢复并保持服务可用性的能力。如果数据库只有一个实例，该实例所在的服务器一旦发生故障，那就很难在短时间内恢复服务。长时间的服务中断会造成很大的损失，因此数据库高可用一般通过多实例副本冗余实现，如果一个实例发生故障，则可以将业务转移到另一个实例，快速恢复服务。

常见的高可用架构有两种，一种是主备架构，另一个是多活架构。

图 1 两种常见的高可用架构

主备架构中，有一个实例是主库，其他实例是备库。主库发送日志给备库，备库通过回放日志来同步主库的数据，一旦主库发生故障，可以选择其中一个备库升主，接管业务。主备架构根据日志类型分两种，物理主备和逻辑主备。

• 物理主备：传输物理日志，备库只读，不可执行写业务，比如 Oracle Dataguard；

• 逻辑主备：传输逻辑日志，备库可以执行写业务，比如 MySQL。多活架构中，每个实例都可以执行读写业务，一个实例宕机后，业务可以转移到其他实例。

多活架构有基于共享存储的共享集群，比如 Oracle RAC，也有基于逻辑日志的多活架构，比如 MySQL 的双主多活。

YashanDB 目前支持物理主备和共享集群两种高可用方案，本文将聚焦于物理主备的高可用介绍。

主备高可用方案挑战

主备高可用方案的挑战通常有以下几点：

• 性能开销：主备高可用方案会对主数据库的性能产生一定的开销，包括增加网络传输、归档 IO 等资源消耗等。在部署主备环境时，需要权衡可用性和性能之间的平衡，还需要考虑部署成本。

• 同步延迟：主备数据库之间的数据同步存在一定的延迟，主要由于网络延迟和日志应用的处理时间所导致。延迟会影响备库只读性能，在主库发生故障时，备库中的数据也可能不是最新的。

• 故障切换：在主备高可用环境中，当主库发生故障时，需要手动或自动进行故障切换，将备库切换为主库。故障切换过程中，需要尽量减少服务中断时间，还要确保数据的完整性和一致性。

• 数据一致性：主备同步至少要保证最终一致性，如果备库需要支持只读，还要保证备库查询的瞬时一致性。

YashanDB 主备针对上述挑战，做了深度优化，使得主备同步性能和自动切换能力达到极致。下面将介绍 YashanDB 高性能主备复制，以及自动故障转移的技术解析。

YashanDB 高性能主备复制

01 整体架构

图 2 YashanDB 物理主备架构图

YashanDB 的物理主备架构如上图所示，左边是主库的组件，右边是备库的组件。

各组件解释如下：

• Log Cache：日志缓存。主库上 Redo 日志会首先写入日志缓存，备库收到 Redo 日志后也会写入日志缓存。

• logFlush：日志刷盘线程。将日志缓存里的 Redo 日志持久化到磁盘。

• logSend：日志发送线程。依次从日志缓存，Redo 文件，归档日志里读取 Redo 日志，发送给备库。

• logRecv：日志接收线程。接收来自主库的 Redo 日志，写入日志缓存。

• archProc：归档线程。在 Redo 文件被复用前，将其拷贝为归档日志文件。

• stbyRcy：备库日志回放线程。依次从日志缓存，Redo 文件，归档日志里读取 Redo 日志，回放 Redo 日志，更新备库数据。

• archSvr：归档发送线程。当备库请求归档日志时，主库将归档日志发送到对端。

• archCli：归档接收线程。当备库出现归档 GAP 时，系那个主库发起请求，并接收来自主库的归档日志文件。

02 主备部署

YashanDB 支持一主多备部署，最多可达 32 个备库。备库可以在线添加，并且一次可以并行添加多个备库。在并行创建备库的过程中，主库只从磁盘读取一次数据，然后将数据转发给多个备库。

YashanDB 还支持级联备库，即备库可以从另一个备库接收 Redo 日志，无需和主库建立连接。级联备可以减少主库的压力，可用于异地容灾。YashanDB 的每个备库可以连接多个级联备库。

图 3 级联备库

03 保护模式

YashanDB 主备对数据的保护是基于事务级别的。一个事务提交前，如果这个事务的日志已经在备库落盘，那么该事务就不会在主库故障后丢失。

为方便用户对数据的保护程度和可用性进行权衡配置，YashanDB 提供 3 种不同的保护模式：

• 最大性能：主机事务提交无需等待备机收到 Redo，备机对主机性能影响最小。该模式下如果主机故障，备机升主后可能丢失数据。

• 最大保护：主机事务提交前，至少有一个备机将日志刷盘。这种模式能保证数据不丢失，但是对主机性能有影响，并且所有备机都断连后，主机事务将阻塞。

• 最大可用：在正常情况下，最大可用和最大保护是一样的。如果所有备机断连，会降级为最大性能模式，不阻塞主机事务。

04 日志发送和接收

YashanDB 在日志发送方面，做了很多优化，来提高日志发送的性能：

• 优先从日志缓存读取 Redo 日志，不产生磁盘读 IO。主备同步正常的情况下，待发送的 Redo 基本都在日志缓存里，因此不会对 Redo 磁盘产生 IO 争抢。只有当日志缓存里的 Redo 被淘汰时，才会从 Redo 文件或归档日志里读取 Redo。

• 日志批量发送，多条 Redo 一次发送，只回一次 ACK（Acknowledgment）。一段时间内产生的 Redo 日志批量发送，这一批 Redo 只需要一个 ACK，这样可以减少网络交互次数，提高吞吐量。

• 异步接收备库的 ACK。每执行一次 Redo 日志发送，并不会等待这批日志的 ACK，而是异步的接收备库的 ACK，不阻塞下一次发送。

• Redo 缓存则发送，不等主库落盘。数据库产生的 Redo 优先写入日志缓存，然后进行本地刷盘，在本地刷盘的同时，日志发送即可进行，减少了一次等 IO 的时间。不过这种方式会带来一个问题，就是在主库发生故障后，备库的 Redo 可能比主库多，这就需要通过一些机制来判断备库的多余 Redo，在后面的未决日志这一章节将介绍这个机制。

• 备库在日志落盘前返回 ACK。如果在备库落盘前返回 ACK，则性能可进一步提升，但是在主备同时故障的情况下，可能有数据丢失的风险。该模式在大部分场景下能做到数据不丢失，同时性能更好，不过因为在极端场景下有丢失数据的风险，所以仅支持最大可用模式下使用。

图 4 日志发送与接收流程

05 归档 GAP

备库停机一段时间后，会落后主库较多 Redo 文件。

YashanDB 的备库重连后，直接从主库日志缓存接收最新 Redo，其余未接收到的 Redo，将通过归档日志拉取线程补齐，这部分归档称为归档 GAP。

由于最新 Redo 是通过日志缓存发送的，所以不会产生额外的 Redo 磁盘 IO，对主库性能影响较小，同时归档拉取线程逐个获取主库归档，可加速备库追赶主库。

图 5 归档 GAP 修复流程

06 未决日志

在最大保护模式下，主库的 Redo 日志没有被备库接收前，这部分日志对应的事务提交将阻塞。如果此时主库宕机，备库升主，新主库不包含这部分日志，旧主库降备后，需要将这部分日志回退，这部分日志称为未决日志。

未决日志可能会回退，其对应的事务不可提交，相应的脏页不能刷盘（如果脏页刷盘后，日志被回退了，就会违反 WAL 原则）。

未决日志不能被备库回放，因为主库上可能没有提交对应的事务。

如果日志被主库和所有同步备持久化，则这部分日志不会被回退，这个日志点称为 commit index。主库维护 commit index 识别未决日志，同时主库会将 commit index 同步给备库。

图 6 未决日志场景 1

上图场景中，主备处于最大保护模式，备库还没有收到主库的 log 4 和 log 5 这两条日志。虽然这两条 Redo 日志在主库落盘了，但是如果主库此时发生故障，备库升主，旧主库降备后，这两条日志将会被回退。

图 7 未决日志场景 2

上图场景中，主库的 log 4 这条日志已经写入主库的日志缓存，并且被发送到备库，但是主库还没有将 log 4 落盘。如果主库此时发生宕机重启，主库上不会包含 log 4 这条日志，备库上这条日志将会被回退。

07 并行回放

YashanDB 的备库支持并行回放，来提高备库回放 Redo 的性能。

备库通过一个协调线程读取和分析 Redo 日志，然后将 Redo 按照会话 ID 哈希分配给后台回放线程，让这些后台线程并行回放 Redo。

并行回放大大提高了回放速率，使得备库 Redo 不积累，备库查询延迟低，并且故障切换的 RTO 很低。

YashanDB 的备库并行回放，复现了主库的 session 执行顺序，可以保证事务瞬时一致性，解决备库读一致性和回放性能难以兼顾的痛点问题。即使主库在高并发业务下，备库查询延迟也可以做到很低。

图 8 备库并行回放

自动故障转移技术解析

当主库发生故障时，需要将某个备库切换为主库，并将业务转移到新的主库上。除了手动执行故障切换，YashanDB 还支持自选主、仲裁切换两种方式的自动故障切换。

01 RAFT 自动切换

YashanDB 的自选主切换是基于 Raft 算法实现的。Raft 是一种共识算法，能确保节点故障或网络分区下保持强一致性。

主备通过心跳检测对方是否存活，主库定期会给所有备库发送心跳，如果备库在超时时间内没有主库的心跳，那么备库就认为主库发生了故障。主库事务提交，要等待多数派节点将 Redo 落盘，除了主库节点，至少要有节点总数/2（下取整）个备库收到主库 Redo 。主库故障，备库心跳超时后，会发起选举投票，如果收到多数派节点的投票，则升为新的主库。投票算法可保证，新主是多数派里 Redo 最多的，而事务提交要等待多数派落盘，因此新主库一定落盘了所有已提交事务的 Redo，不会丢数据。

Raft 的每次选举都会产生一个新的任期（term），在一个任期内，最多只有一个主库。

Raft 将系统中的角色分为 Leader、Follower 和 Candidate。工程上为了提高系统稳定性，加入了 PreCandidate 角色：

• Leader：对应于主库，向 Follower 发送 Redo 日志；当日志同步到多数派节点上后，通知 Follower 更新 commit index。

• Follower：对应于稳态下的备库，接受并持久化 Leader 发送的日志，并回放 commit index 之前的日志。

• Candidate：对应于选举中的备库，从 PreCandidate 到 Leader 的中间角色。

• PreCandidate：对应于选举中的备库，从 Follower 到 Candidate 的中间角色。

图 9 Raft 节点状态转移图

如上图所示，数据库启动后都是 Follower 角色，如果没有收到 Leader 的心跳，到达超时时间后，会发起预选举。预选举成功后，会增加自己的任期然后发起正式选举，正式选举成功后，就成为 Leader，即从备库升为主库。在选举过程中，如果遇到任期比自己高的节点，或者发现当前任期的 Leader，则会中断选举，回到 Follower 角色。

02 仲裁切换

Raft 至少需要 3 个节点，不适合一主一备的自动切换，为此 YashanDB 提供了基于外部组件的一主一备仲裁切换功能。

yasom 是 YashanDB 的轻量级的数据库管理进程，一般部署在非数据库服务器，可对主备状态进行监控。yasom 和数据库之间有个 yasagent 进程进行代理通信，yasagent 部署在数据库所在服务器。

yasom 检测到主库异常后，在满足切换条件的情况下，给备库下发 failover 命令进行切换。切换条件为 yasom 和备库都感知不到主库，如果其中任一个能感知到主库，说明主库正常。

图 10 OM 仲裁切换场景

如上图 3 种情况，情况 1 表示主库所在服务器故障，yasom 和备库都感知不到主库，可以切换。情况 2 表示主库进程故障宕机，yasom 和备库都感知不到主库，可以切换。情况 3 表示 yasom 和主库所在服务器网络异常，但是主库和备库之间网络正常，此时不会切换。

零丢失模式

零丢失模式下，只有确定备库不丢失数据的情况下，才可以升主，牺牲一定的可用性，但是不会丢失数据。

• 主备优先使用最大保护模式，保证数据全部同步到备库。

• 当备库异常时，yasom 将主库切换为最大可用模式，保证数据库可用，不阻塞业务。

• 主库故障时，如果处于最大保护模式，则 yasom 进行自动切换。

• 主库故障时，如果处于最大可用模式，则 yasom 不会切换，因为有数据丢失的风险，此时需要人工介入。

脑裂自动修复

非零丢失模式下，旧主库和新主库的数据可能不一致，旧主库降备后，与新主库发生脑裂。

yasom 发现备库脑裂后，将下发脑裂修复命令，修复备库不一致的数据，使主备复制恢复正常。

首先找到主备的日志分歧点，然后扫描备库 Redo 得到分歧点之后修改过的页面，将这些页面的 ID 发给主库，从主库获取对应页面并覆盖备库本地文件。再以分歧点 lsn 为基线，将主库上大于该 lsn 的数据页面发送到备库覆盖，最后将主库分歧点之后的 Redo 发送到备库，进行回放。回放完成后，主备将正常同步 Redo，脑裂修复完成。

图 11 脑裂修复流程

总结及未来规划

在客户实际运用数据库的过程中，性能与业务连续性无疑是最为重要的两大考量因素。尽管主备高可用方案在业界极为普遍，但在真实业务场景中仍面临多重挑战。我们在架构技术与编程实现等方面进行了深入的优化工作，以提升主备部署模式的同步性能及高可用保障。接下来，我们会继续丰富功能和性能，还将在以下几个方面继续打磨和增强：

• 逻辑主备：主要用于逻辑复制，滚动升级，HTAP 场景；

• 条件故障切换：非网络故障，比如文件损坏，服务器资源异常时自动切换。