随着 AIGC 和大模型的浪潮席卷全球，向量数据库作为处理和检索海量非结构化数据的核心引擎，其重要性日益凸显。为了确保数据的多副本容灾和一致性，数据库普遍采用成熟的 Raft 协议来构建多副本架构，通过 Raft 协议和高可靠的云盘，数据被复制成三份甚至更多，似乎已经构筑了一套完备的数据的读写和基本的容灾能力，然而，这样的高可用架构真的就万无一失了吗？

当人为的误删除、程序 Bug 的致命一击发生时，这些“错误”操作也会被忠实地同步到所有副本，导致数据瞬间灰飞烟灭——此时我们才意识到，仅靠多副本远不足够，那么，我们应该如何在海量分片间保证数据的一致性快照？ 

基于以上痛点，腾讯云 NoSQL 团队自研了完整的备份恢复功能，解决了分布式架构下数据与元数据的动态一致性难题，构建了一套对业务影响极低的精确时间点备份恢复系统。从功能设计到发布后，整体未发生过一起数据故障和间接引发的宕机故障。 腾讯云 NoSQL 团队是如何做到这一点的？本文将带你一探究竟。

1 自研数据库中备份各类问题与挑战

1.1 Raft+云盘多副本，难道还不够？

TencentVDB 源自 PCG 的 OLAMA 平台，并持续共建开发，该平台的构建的基础架构与众多数据库类似，基于 Raft 协议来确保数据的多副本容灾和一致性，如下图所示：

如上所示，VDB 从数据面将 1 个 collection 划分为 1-N 个 shard（分片）放在 Worker0-N 中对客户直接进行访问服务，每个 shard 是一个 raft 组，或者说每个 shard 是 1 个 leader 多个 Follower。VDB 管理面（Master）是对元数据的管理，采用 1Leader+4Follower 的方式来确保元数据的可靠性。

按照 raft 协议的基本逻辑，数据的读写和基本的容灾能力是具备的：

• 多数派写入成功则会认为成功，如果是 1 主 2 从，2 个节点写入成功则认为成功，那么在其中任意一个节点出现意外宕机或主动运维重启过程中不会引发读写异常。

• 任何一份数据损坏都可以恢复，因为最少 2 份数据是完整的，所以即使是 Leader 数据盘损坏也依然可以确保数据不丢失。

• 3 份数据最终是一致的，虽然写入是多数派成功认为成功，但依旧会通过 Raft 日志确保最终 3 个副本的数据是一致的。

• 云盘本身的高可靠性，在云上部署的 VDB 是基于云盘来完成，云盘本身也是多可用区多副本确保 9 个 9 以的可靠性。

为什么这样的数据可靠性还不够？

上述数据的可靠更多还是偏于机机正常访问为前提下，出现宕机、运维重启、磁盘损坏、文件损坏等可能发生的数据丢失的容灾方法，但在实际运行过程中，还存在以下两类情况：

• 人为误（或恶意）删除，人为误删除数据、表、库的时候（甚至于将回收站清空），即使数据多个副本会被同时删除。

• 程序 Bug，由于程序发布 bug、被恶意植入执行代码等方式，导致数据和结构被删除，此时多副本依然会被同时删除。

• 需要克隆实例，用户因为需要对比数据、性能、版本差异，需要克隆一份某时刻的数据是一种不错的选择。

“备份恢复”成为保障客户数据的最后一道防线。向量数据库早期更聚焦于向量算法检索和工程优化。随着业务需求的快速发展，越来越多的客户将业务标量数据、原始文本内容、图片和视频地址等具备业务含义的数据放入到向量数据库中，以便于通过向量数据库获得更多更直接的非结构化数据处理。

由此客户对于向量数据库的数据可靠性要求更高，对备份恢复的客观诉求变得越发强烈，VDB 内核团队基于分布式向量数据库自研了完整的向量数据库备份恢复，在这个过程中相对于传统数据库会有诸多区别和不同的技术挑战，本文将详细展开这些细节分享给大家。

1.2 相对传数据库的困难和挑战

在自研分布式向量数据库中，备份恢复机制面临以下几个关键难点：

• 备份恢复系统需完全自研，缺乏现成方案

与传统数据库不同，自研向量数据库无法直接沿用成熟的开源或商业备份工具，几乎从 0 设计和构建整套备份恢复流程，并针对向量数据的高维、相似性检索等特性做专门优化。

• 分布式多分片与多副本间的一致性保障

数据表会被拆分为多个分片（Shard），分散在不同节点上，每个分片又存在多个副本。在备份瞬间，需要确保所有分片及其副本在时序上保持一致，否则可能因数据状态不一致导致数据错乱。

• Braft 框架 log 中缺乏时间戳带来的恢复效果

基于默认 BRaft 框架的日志中未记录时间戳，导致无法直接基于指定时间点进行恢复。VDB 团队通过改写日志格式，引入时间戳来增强能力，但这又会带来新旧版本兼容性升级的挑战，这都将在本文后面逐步展开。

• 元数据与节点状态在备份过程中的动态一致性问题

Shard（分片）的分布、副本位置、节点 IP、角色等关键信息均由元数据库统一管理。备份过程中若元数据发生变更（如频繁新建和删除表），需确保元数据与各节点实际数据状态的一致性。而在恢复阶段，需要对元数据中的异常进行处理，由于恢复的机器 IP 已发生改变，也需处理对节点 IP 元信息进行依赖解耦处理，会进一步增加了实现复杂度。

2 核心技术点的落地

2.1 备份核心点：一致性与完整性

多节点数据毫秒级一致

当外部发起 T0 备份时，其核心目标是为恢复 T0 时刻的数据。然而在分布式环境中，该备份的实际执行会因网络与预处理延迟，导致以下情况：

• 备份时间点分散：各节点实际备份时刻并不统一，而是分布在 T0 之后的多个时间点。

• 恢复数据不一致：恢复所得的数据并非一个统一的 T0 时间点快照，不同节点的数据存在时间差。

• 中间操作状态混杂：在 T0 到各节点完成备份的时间窗口内，若发生 CRUD 操作，会导致部分节点包含了此变更，而其他节点未包含，从而引发数据状态不一致。

VDB 面对上述客观问题，我们考虑的是通过上次本地快照+Raft 日志的方式，确保备份时刻比发起备份的 T0 时刻更晚，那么就能确保恢复阶段的数据就可以通过回放到 T0 时刻的日志来确保时序的一致性（这里理解的基础是时钟同步的差距低于 ms 级）。VDB 备份前和备份中会有以下行为：

• VDB 周期性判断，如果数据发生变化较多，对原始数据进行本地硬链接（放在 RocksDB 中，包含标量和向量），这个是相对 T0 更早的时刻，标记为：Tx1

• VDB 周期性判断，如果数据发生变化较多，对索引数据的进行本地快照（索引数据存放在磁盘上的文件），也是相对 T0 更早的时刻，标记为 Tx2

Tx1 是本地磁盘硬链接速度非常快速，然后再对索引数据备份开始时会先 fork 一份内存，在此期间会短暂阻塞写入，确保 Tx1 和 Tx2 之间数据未发生变化。

• 备份过程中，并对 Raft 日志进行硬链接处理后再进行远程备份

• 备份过程中，由 Master 记录备份的时间点是 T0，以便于恢复时统一用该时刻

VDB 在恢复到新实例阶段处理手段：

恢复过程禁写：设置特定状态，该阶段禁止外部写入，恢复完成后才开放

先恢复原始（RocksDB）数据：此时恢复出来的原始数据是 Tx1，早于 T0。

再回复索引数据（Index）数据：此时恢复出来的索引数据是 Tx2，前文中提到 Tx1-Tx2 数据保持一致，所以索引也可以认为是 Tx1 时刻的索引。

通过 Raft 日志恢复到 T0 时刻：根据 Master 记录的 T0 时刻，回放 Tx1-T0 这个时段日志，确保各个节点的即使快照和备份时间不一致，也能最终在毫秒级达成一致。

补充：关于 braft 框架默认的 raft log 的改写：

VDB 是基于 braft 框架来完成的，其框架本身提供的 raft log 并没有标志 timestamp 信息，而是通过类似序列号的方式来表达的。

所以 VDB 在完成上述备份过程中之前需要先更改整体的日志格式，而在这个过程中，会引发旧版本日志和新版本日志不兼容的情况，例如在升级过程中节点间传递 raft 日志，旧版本日志和新版本日志相互不兼容。为了解决这个问题，VDB 做了以下处理：

• 新版本的代码兼容旧版本的日志，升级过程中作为 Follower 可以接收以前的日志。

• 提供升级模式状态，不影响读写，在此状态下，新版本也依然按照旧版本的日志写入，升级过程中作为 Leader 时可以让旧版本节点识别到日志。

• 在所有节点升级完成后，将状态更改为正常服务，确保全部使用新日志格式进行写入，并立即完成一份快照，以确保从此时刻起，就可以使用备份恢复。

分布式元数据状态一致

除上述数据一致外，我们还会遇到的问题是，当 T0 时刻发起备份后，T1 时刻才真正开始备份，此时 T0 到 T1 之间用户发起了新增表、删除表、添加索引字段、删除库等行为，则会导致元数据不一致，例如：

● 恢复时元数据多了一些新增的表，但数据节点上备份的数据中没有该表

● 恢复时元数据少了一些表，导致无法恢复出来这些数据

分布式元数据状态一致

除上述数据一致外，我们还会遇到的问题是，当 T0 时刻发起备份后，T1 时刻才真正开始备份，此时 T0 到 T1 之间用户发起了新增表、删除表、添加索引字段、删除库等行为，则会导致元数据不一致，例如：

● 恢复时元数据多了一些新增的表，但数据节点上备份的数据中没有该表

● 恢复时元数据少了一些表，导致无法恢复出来这些数据

元数据是否类似数据面一样，通过快照+Raft log 回放来实现？

元数据的日志是对表和库的增删改，而该行为是不可发生 REDO 的，例如建表再发生 REDO 就会报错，所以还需要采用其它的方式来完成。

为此 VDB 先引入了状态机，来控制管理节点（Master）来控制任务处理过程中的信息：

• IDLE，日常空闲状态，不做任何控制行为

• IN-PROGRESS，发起备份 Maser 立即修改的状态，并向所有的数据节点下发备份任务

• WAITING，管理节点（Master）开始等待所有 Worker 节点是否收到备份，如果收到则认为下发结束，否则认为本次备份失败。

引入上述状态机后，发起备份会第一时间修改状态，此时如果外部发起对表的新增、删除、修改操作会被短期阻塞或拒绝（根据策略来决定），然后将 T0 时刻的元数据快照并保存，并通知各个数据节点（Worker）开始备份指定的表，进一步将进行如下处理：

• 快速释放锁：元数据本地快照成功后不再加锁，允许外部对表和库进行增删改操作

• 新增表：如果期间发生新增表操作，新增的表不会被备份（各数据节点需要备份的表已在加锁阶段确定）

• 新增和删除索引：该行为在 VDB 中不会真正去删除数据，元数据加锁阶段已被保存。

• 发生删除表操作：元数据会被删除，但元数据已在加锁阶段被保存快照，而数据节点的索引、原始数据、日志会暂时标记删除，外部访问不到该表。然后通过缓清理的方式（询问 Master 是否可以清理），使得数据在备份期间不会因为删除行为而被实际清理。

数据和日志的完整性

在数据备份的过程时，数据和日志正在写入，从内核程序角度会认为写入成功，但操作系统可能尚未刷盘（部分数据还在缓冲区中），此时进行磁盘备份的时候，会导致数据和日志的不完整，例如最后一条日志可能只有一半被刷盘。操作系统的机制无法避免，只能充分利用 OS 的机制，针对数据和日志做一些特殊处理，使得最终的数据是一致的：

● 数据快照阶段处理：确保数据本身在快照时是被强制刷盘的（fsync），以确保备份的快照文件在那个时刻是完整的。

● 日志实时写入处理：确保日志在备份时刻前的日志都已经被强制刷盘一次，备份时刻 T0 发起后，可能还会有外部请求写入数据到缓冲区未落盘，导致半条日志的情况，但那些日志是在 T0 时刻过后的，所以只需要对日志校验部分进行特殊处理，就可以。

2.2 丝滑体验：降低备份对业务的影响

VectorDB 的备份过程中，主要有 3 个核心步骤：

● 本地硬链接（含上面提到的数据、索引、日志、元数据），实现本地备份

● 通过云巢团队 DBS 系统，间接使用 CBS 盘快照，实现远程备份

因此在备份过程中会几个明显的特点：

• 业务影响趋近 0：无论是本地硬链接，还是 CBS 盘快照，对业务的 IO 影响几乎趋近 0，同时几乎不占用系统的 CPU 和内存资源。

• 急速备份：

  本地硬链接几乎在压秒级完成，在现网业务中部分运行时数据显示，对一个 20TB 的向量库进行备份，经过元数据加锁分发，以及所有分片日志的本地备份全部完成在 20s 内完成。

  CBS 盘的快照在首次备份成功后，再进行快照备份，其取决于磁盘更新的量，不需要将整个磁盘的数据拷贝。

• 本地盘（NVMe）拷贝减少

  将业务 Raft 日志依然放在 CBS 盘，这部分内容可能会超过数据本身的大小，确保备份时这部分数据不再从本地盘拷贝出来。

  本地盘 NVMe 主要存放索引数据，将其与日志分离，可以更好的保障客户的检索服务使用磁盘时具备稳定的 IOPS。

  备份期间该数据的硬链接会被建立在本地盘并在备份时直接进行远程备份，以减少对 CBS 盘的写入。此时如将数据拷贝到 CBS 盘统一备份，可能会导致 CBS 盘的写入带宽被拉高，从而导致业务写入时 Raft 日志落盘变慢，间接导致写入变慢，极端情况下会导致整个系统的处理线程会消耗光，无法为业务提供查询服务。

2.3 降低 RTO：恢复一致性与速率

关于数据和元数据的一致性，在前面已提到。除此之外，元数据还包含了各个数据节点的 IP 地址，数据分片和其副本在那个节点上（IP 地址），以及其角色，以便于在日常运维和异常宕机时便于容灾处理。然后这一方式使得备份后的元数据在恢复阶段变得麻烦，所以在恢复阶段 VDB 会采用以下动作去完成一致性和速率提升：

● 按照备份恢复元数据到 Master 节点

● 数据节点 Worker 按照 1：1 恢复到新的数据节点，此时为恢复状态，暂不进行各类心跳处理

● 根据新节点顺序，将元数据的 IP 地址进行修改，让 Master 与新的一批 Worker 进行通信调度

● 每个 Woker 通过快照恢复到新的 CBS 盘

● 每个 CBS 盘上并行装载分片数据到内存，这样充分利用多台机器云盘的最大带宽装载数据

3 运行情况

在基于纯自研的分布式数据库备份恢复，从设计到实现发布后，整体未发生过一起数据故障和间接引发的宕机故障，备份和恢复的成功率几乎也是：

• 备份成功率：99.99%，备份次数达到数十万次，部分未成功的例子也已经寻求到解法会在后续版本中完善

• 恢复成功率：客户侧使用 100%，滚动流水线模拟 99.95%（常态化模拟备份恢复），未成功的部分也已寻求到解法会在后续版本中完善。

4 需更进一步

今天 VDB 主要是做到备份时刻的一致性处理，为了更好的支持备份恢复以缩小 RPO，需要提供更加强大的备份恢复能力：

• 分钟/秒级实时备份，基于日志文件变更的备份，也可提供 CDC 能力由外部订阅来完成日志的事实流式备份。

• 数据表无删除的回收站能力，以便于误操作时可以快速恢复表，而不需要经历整库的恢复流程。

• 数据级 UNDO 能力，根据日志反推回滚行为，用户如发生局部数据修改错误或删除错误，可根据需要，对某个表的某个过滤条件下的数据，进行部分快速闪回。