跳转到主要内容
只读副本可让您为主节点 Managed Postgres 数据库创建一个或多个副本。这些副本会通过 PostgreSQL 的原生复制持续跟随主节点数据库,及时同步变更。 要管理只读副本,请点击仓库上的编辑图标: 这将打开仓库对话框,您可以在其中查看现有服务并创建新的只读副本:

管理只读副本

只读副本 页面提供两种视图,可通过右上角的 FlowTable 控件进行切换。 Flow 视图显示复制拓扑——顶部是你的主节点实例,箭头向下指向每个已附加的副本,让你一眼即可查看层级、区域和状态: Table 视图会列出每个副本的服务名称、云提供商和区域、服务状态、创建时间,以及 Detach service 操作: 要创建新的副本,请在任一视图右上角单击 Create read replica

为何使用只读副本

可扩展性

只读副本可将读密集型工作负载分散到多个专用实例上,从而实现数据库的横向扩展。这对于报表查询、分析处理和实时仪表盘尤其有价值,否则这些负载就会与生产环境流量争夺资源。

隔离

通过将分析查询和商业智能查询定向到只读副本,可以让主实例专注于写入操作和关键事务工作负载,并保持良好的响应能力。这种隔离可提升整个系统的性能和可预测性。同时,您也无需向分析或报表工具授予写权限——它们可以安全地在副本上运行,而不会有意外修改数据的风险。

业务连续性

只读副本在灾难恢复中可发挥关键作用。如果主数据库发生故障,只读副本可以提升为主节点,从而将停机时间和数据丢失降到最低。除了高可用待机节点外,这还提供了额外一层的韧性保障。

只读副本的工作原理

Managed Postgres 中的只读副本采用 WAL shipping 架构,而非流式复制。这种设计旨在尽量降低对主节点数据库的影响。

通过对象存储传输 WAL

当主节点数据库处理事务时,会生成预写日志 (WAL) 记录。这些 WAL 分段会持续归档到对象存储 (S3) 中。只读副本会从对象存储中拉取并重放这些 WAL 分段,以与主节点保持同步。 这种架构不同于高可用待机节点,后者通过与主节点的直接连接使用流式复制。

为什么我们选择这种方式

我们有意将只读副本设计为从对象存储中读取 WAL,而不是作为流式备用节点直接连接到主节点。这样可以让只读副本与主数据库实现完全隔离:
  • 主节点零复制开销:只读副本不会与主节点保持流式连接,因此不会给你的关键工作负载增加任何 CPU、内存或网络负载。
  • 独立扩缩容:你可以添加或移除只读副本,而不会对主节点性能造成任何影响。
  • 网络隔离:只读副本在各自独立的网络环境中运行,并使用单独的连接端点。

复制延迟特性

这种架构的代价在于复制延迟。WAL 分段会按固定时间间隔从主节点归档 (通常为每 60 秒一次,或在分段写满时归档,以先发生者为准) 。这意味着在正常情况下,只读副本可能会比主节点滞后数十秒。 对于大多数读扩缩容场景——报表、分析、仪表盘——这种延迟是可以接受的。如果你的应用需要近实时读取,请考虑是否可以将查询定向到主节点,或者这一时间窗口内的最终一致性是否能够满足你的要求。
最后修改于 2026年6月10日