概述

读副本 (Read Replica) 是 GreptimeDB 企业集群版中的一项重要功能，旨在提升系统的整体读写性能与可扩展性。

注意

读副本（Follower Region）依赖对象存储（例如 AWS S3）。 由于 Follower Region 可能被调度到不同的 Datanode，它们必须通过对象存储共享 Region 数据；不支持仅使用本地存储的集群。

在允许查询从 Follower Region 读取之前，请确保在 Metasrv 和所有 Datanode 上启用 GC。只有在启用 GC 时，才支持从 Follower Region 读取。

在读副本机制中，客户端将数据写入写副本 (Leader Region)，随后由 Leader Region 将数据同步到 Follower Region。Follower Region 作为 Leader Region 的只读副本。通过配置 Datanode 组，可以将 Leader Region 与 Follower Region 分别部署在不同的 Datanode 节点上，读写请求能够有效隔离，避免资源争用，从而获得更平滑的读写体验：

原理

GreptimeDB 企业集群版基于存算分离架构，使副本间的数据同步几乎零成本；同时，读副本也能以极低延迟读取到最新写入的数据。下面分别介绍数据同步与数据读取机制。

数据同步

在 GreptimeDB 中，计算与存储解耦，所有数据以 SST 文件的形式存放在对象存储中。因此，Leader Region 与 Follower Region 之间无需复制 SST 文件本体，只需同步其元信息即可。元信息相比 SST 文件体量小得多，因而同步开销极低。一旦元信息同步完成，读副本便“拥有”相同的 SST 文件，从而可以读取数据：

在实现上，SST 文件的元信息持久化在一个特殊的 manifest 文件中（同样位于对象存储）。每个 manifest 文件都有唯一的版本号。Leader Region 与 Follower Region 之间的同步，本质上就是同步这个版本号——一个简单的整数，开销极小。Follower Region 获得版本号后即可从对象存储拉取对应的 manifest 文件，从而获得 Leader Region 生成的 SST 元信息。

manifest 版本号通过 Region 与 Metasrv 之间的心跳进行同步：Leader Region 在发往 Metasrv 的心跳中携带版本号，Metasrv 在回复 Follower Region 的心跳中将其下发：

可以看出，若仅依赖 SST 文件层面的同步，读副本读到新写入数据的延迟约为 Leader Region 与 Follower Region 分别到 Metasrv 的心跳间隔之和。以默认 3 秒心跳为例，读副本通常只能读到 3–6 秒前已写入并 flush 至对象存储的数据。对于对数据“新鲜度”要求不高的场景已足够，但若需要近实时读取，还需配合下述机制。

数据读取

最新写入的数据首先保存在 Leader Region 的 memtable 中。为了读到这些最新数据，Follower Region 需要向 Leader Region 请求 memtable 数据，并与自身通过前述同步机制获得的 SST 数据合并，从而向客户端提供包含最新写入的完整结果集：

Follower Region 通过内部 gRPC 接口从 Leader Region 获取 memtable 数据。该过程会给 Leader Region 带来一定读负载，但由于 memtable 位于内存且大小受限，通常影响可控。

下一步

• 管理读副本
• 从读副本查询