平台

只读副本

跨多个区域部署只读数据库，实现更低延迟和更优资源管理。

只读副本是与主数据库保持同步的附加数据库。您可以从只读副本读取数据，这有助于：

  • 负载均衡：只读副本减轻主数据库的负载。例如，您可以将复杂分析查询分配给只读副本，而将主数据库专用于面向用户的创建、更新和删除操作。
  • 降低延迟：对于拥有全球用户的项目，可以在靠近用户的位置部署附加数据库以减少延迟。
  • 数据冗余：只读副本提供数据冗余保障。

关于只读副本

在启动Supabase项目时初始创建的数据库是您的主数据库。只读副本通过"复制"过程与主数据库保持同步。复制过程采用异步机制，确保主数据库上的事务不会被阻塞。主数据库更新与只读副本接收变更之间存在延迟，这种延迟称为"复制延迟"。

只读副本仅支持数据读取操作，这与主数据库形成对比：

查询插入更新删除
主数据库✅✅✅✅
只读副本✅---

先决条件

项目必须满足以下要求才能使用读取副本：

  1. 运行在AWS上
  2. 至少使用小型计算附加组件
    • 读取副本会在与主数据库相同的计算实例上启动，以保持数据同步
  3. 运行Postgres 15+版本
  4. 使用物理备份
    • 如果使用PITR(时间点恢复)，物理备份会自动启用
    • 如果不使用PITR，您可以在设置读取副本的过程中切换到物理备份。请注意，物理备份无法像逻辑备份那样从仪表板下载

开始使用

要添加读取副本，请前往仪表板的基础设施设置页面。

使用XL或更大计算附加组件的项目最多可创建五个读取副本。使用小于XL计算附加组件的项目最多可创建两个读取副本。所有读取副本都会继承其主数据库的计算规格。

部署只读副本

只读副本的部署以物理备份为起点，结合WAL文件归档和从主数据库直接复制来实现数据同步。这两个组件可能需要较长时间才能完成。从物理备份恢复的时长大致取决于项目数据库的大小，两者呈正相关关系。而通过WAL归档和直接复制追平主数据库所需的时间则取决于主数据库的活动水平：活动越频繁的数据库会产生更多需要处理的WAL文件。

随着部署进度推进，仪表板会显示每个组件的预估完成时间。

出现"初始化失败"意味着什么？

状态显示初始化失败表示只读副本部署失败。可能导致部署失败的几种情况：

  • 底层实例启动失败
  • 网络问题导致无法连接主数据库
  • 主数据库与只读副本间可能存在不兼容的数据库设置
  • 平台问题

您可以安全地删除这个失败的只读副本，若遇到暂时性问题，可以尝试重新部署一个。但如果您的项目持续出现只读副本部署失败，请查看我们的状态页面了解是否有进行中的故障事件，或在此处提交支持工单。为便于调查，请保留最近失败的只读副本不要删除。

功能特性

只读副本提供以下功能：

专用端点

每个只读副本(Read Replica)都拥有专属的数据库和API端点。

只读副本仅支持来自REST API的GET请求。如果您通过REST API调用只读Postgres函数，请确保设置get: true选项。

对Supabase其他产品（如Auth、Storage和Realtime）的请求无法使用只读副本或其API端点。未来将增加对更多产品的支持。

如果您使用IPv4附加组件，只读副本的数据库端点也将使用IPv4附加组件。

专用连接池

通过Supavisor为每个只读副本提供连接池服务。在数据库设置页面的连接字符串下查找连接字符串。

API 负载均衡器

系统部署了一个负载均衡器，用于自动平衡主数据库与只读副本之间的请求流量。您可以在API设置页面找到其端点。

该负载均衡器为数据API请求提供地理位置路由功能，确保GET请求会自动路由到距离用户最近的数据库，从而获得最低延迟。非GET请求也可以通过此端点发送，它们将被路由到主数据库处理。

您还可以通过此负载均衡器与Supabase各项服务（认证、边缘函数、实时通信和存储）进行交互，无需考虑在不同场景下应该使用哪个端点。不过，这些服务的区域路由功能目前尚未开放，但即将推出。

若要通过REST API在只读副本上调用Postgres只读函数，请使用get: true选项。

如果从项目中移除所有只读副本，负载均衡器及其端点也将被移除。请在移除前确保将请求重定向回主数据库。

通过 SQL 编辑器查询

在 SQL 编辑器中，您可以选择是否要在特定的只读副本上运行查询。

日志记录

当只读副本部署后，它会从以下服务生成日志：

日志浏览器中的视图会自动按数据库筛选，默认显示主数据库的日志。可以通过日志浏览器页面右上角的Source按钮切换查看其他数据库的日志。

对于API日志，日志也可能来自API负载均衡器。最终处理请求的上游数据库可以在Redirect Identifier字段中找到。这相当于查询底层日志时的metadata.load_balancer_redirect_identifier。

指标监控

只读副本的可观测性和指标可在 Supabase 仪表板中查看。通过切换数据源选项，可以在数据库报告页面查看特定只读副本的资源利用率。同样地，通过API报告页面也可监控流经只读副本或负载均衡器API端点的请求指标。

我们建议将项目指标接入您自己的监控环境。如果已为项目配置了指标采集管道，您可以更新配置以同时采集只读副本的指标数据。

集中式配置管理

通过仪表板配置的所有设置将在项目的所有数据库间同步传播。这确保任何只读副本都不会与主数据库或其他只读副本失去同步。

只读副本限制的操作

项目升级与数据恢复

以下操作需要先停止项目的所有只读副本才能执行：

  1. 项目升级
  2. 数据恢复

这些操作完成后才能重新部署只读副本。

关于数据复制

我们采用混合方法将数据从主数据库复制到其只读副本，结合了原生的流式复制和基于文件的日志传送两种机制。

流式复制

Postgres 会在数据库变更时生成预写日志(WAL)。通过流式复制，这些变更会从主服务器实时传输到只读副本服务器。仅凭 WAL 就足以将数据库重建至当前状态。

这种复制方式速度很快，因为变更直接从主服务器流式传输到只读副本。然而，当只读副本无法跟上主服务器的 WAL 变更时就会面临挑战。这种情况可能发生在只读副本规格过小、硬件性能不足或运行较重工作负载时。

为解决这个问题，Postgres 提供了可调配置参数，如 wal_keep_size 用于调整主服务器保留的 WAL 大小。如果只读副本在 WAL 超过 wal_keep_size 设置前未能"追上"，复制过程就会终止。参数调优需要一定技巧——不同场景下所需的 WAL 量是变化的。

基于文件的日志传输

在这种复制方式中，主服务器持续将 WAL 变更缓冲到本地文件，然后将文件发送给只读副本。如果存在多个只读副本，文件也可能被发送到所有副本都能访问的中间位置。只读副本随后读取 WAL 文件并应用这些变更。由于主服务器需要先在本地缓冲变更，这种方式的复制延迟高于流式复制。同时也意味着如果主服务器在文件传输完成前宕机，存在 WAL 变更无法到达只读副本的小概率风险。这种情况下，使用流式复制的副本(在大多数情况下)会比使用基于文件日志传输的副本保持更最新的状态。

基于文件的日志传输 🤝 流式复制

我们将这两种方法结合起来，实现快速、稳定且可靠的复制。每种方法都能弥补另一种方法的局限性。流式复制最大限度地减少了复制延迟，而基于文件的日志传输则提供了后备方案。对于基于文件的日志传输，我们使用现有的时间点恢复(PITR)基础设施。我们定期使用开源归档和恢复工具WAL-G从主数据库归档文件，并将WAL文件传输到S3。

我们将其与流式复制相结合以减少复制延迟。一旦WAL-G文件从S3同步完成，只读副本就会连接到主数据库并直接流式传输WAL日志。

监控复制延迟

您可以通过仪表板监控特定只读副本(Read Replica)的复制延迟。在数据库报告页面上，只读副本会在副本信息部分显示一个额外的图表，展示以秒为单位的历史复制延迟。实时复制延迟可以在基础设施设置页面上查看，这个数值显示在只读副本的顶部。请注意，没有一个单一的阈值可以表明何时需要处理复制延迟，这完全取决于您项目的需求。

如果您已经将项目指标导入到自己的监控环境中，也可以通过以下指标跟踪复制延迟并设置告警：physical_replication_lag_physical_replica_lag_seconds。

导致高复制延迟的常见原因包括：

  1. 主数据库上的表被独占锁定 诸如drop table、reindex等操作会对表施加访问独占锁(Access Exclusive lock)，这可能导致在锁持续期间复制延迟不断增加。

  2. 数据库资源限制 如果项目资源配置不足，主库或副本上的高负载使用都可能导致高复制延迟，这包括所使用磁盘的特性(IOPS、吞吐量等)。

  3. 主数据库上的长时间运行事务 在主库上长时间运行的事务也会导致高复制延迟。您可以使用pg_stat_activity视图来识别并在必要时终止这类事务。需要注意的是，pg_stat_activity是实时视图，不会显示过去可能长期活跃的事务历史数据。

高复制延迟可能导致针对受影响只读副本执行的查询返回过时数据。

您还可以参考以下相关资源：

其他事项

重启或计算附加组件变更行为

当使用只读副本的项目重启或计算附加组件大小变更时，主数据库会首先重启。在此期间，只读副本仍保持可用。

一旦主数据库完成重启（或在计算附加组件变更情况下的调整大小）并恢复可用状态，所有只读副本将同时重启（并在需要时调整大小）。

计费

有关费用计算的详细说明，请参阅管理只读副本使用量。