Supabase 怎么部署 Read Replicas 降低跨区域读延迟？前置条件有哪些？

Supabase 怎么部署 Read Replicas 降低跨区域读延迟？前置条件有哪些？

【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase

如果你的项目用户分布在多个地区，直连 Primary 数据库的读请求会跨越网络带来明显延迟。Supabase 的 Read Replicas 允许你在其他区域部署只读数据库副本，通过内置的 API 负载均衡器把GET请求地理路由（geo-routing）到离用户最近的数据库，从而降低跨区域读延迟。部署完成前，需要先确认项目满足计划、云厂商、计算规格、Postgres 版本和备份方式这几类前置条件；不满足时无法创建副本。

前置条件：先核对这 5 项

Supabase 官方列出的 Read Replicas 使用要求如下（来源：Getting started with Read Replicas）：

1. 付费计划：Read Replicas 仅对 Pro、Team 和 Enterprise 计划的所有项目可用。
2. 运行在 AWS 上：项目必须部署在 AWS。
3. 至少 Small 计算规格：Read Replicas 启动在与 Primary 相同的计算实例上以跟上数据变化。Small 及以下的规格（含 Micro、Nano）不满足要求。具体规格可参考 Compute and Disk。
4. Postgres 15 及以上：运行旧版 Postgres 的项目需要先升级到最新平台版本。
5. 未使用 legacy logical backups：使用 Point in Time Recovery（PITR）的项目会自动启用物理备份，因此不受影响（参见 Backups 的 PITR 章节）。

此外还有一个容易被忽略的限制：Available regions 文档说明通用区域（General regions）尚不支持 Read Replicas，也不支持通过 API 管理。也就是说，通过 API 创建副本时，read_replica_region必须填具体的 AWS 区域 ID（如us-east-1），而不是 "Europe" 这类通用区域分组。

副本数量也有上限：

• 计算规格为XL 或更大的项目：最多创建5 个Read Replicas；
• 计算规格小于 XL的项目：最多创建2 个Read Replicas；
• 所有 Read Replicas 都继承 Primary 的计算规格大小。

计费上，每个 Read Replica 是独立数据库，按其计算小时、磁盘大小、额外配置的 IOPS/Throughput 以及 IPv4（如启用）计费，磁盘大小为 Primary 磁盘的 1.25 倍（用于存放 WAL 档案），且不受 Spend Cap 保护，详见 Manage Read Replica usage。

创建一个 Read Replica

主路径在 Dashboard 操作：进入项目的Infrastructure设置页（Dashboard 的 Settings → Infrastructure），在页面上创建副本并选择目标区域。

替代路径是使用 Management API（文档标注为 beta 功能）。下面的命令直接来自官方文档，your-access-token和your-project-ref需要替换为你自己的值：access token 在 Dashboard 的 Account → Tokens 页面生成，project ref 是项目引用标识。

# Get your access token from https://supabase.com/dashboard/account/tokens export SUPABASE_ACCESS_TOKEN="your-access-token" export PROJECT_REF="your-project-ref" # Create a new Read Replica curl -X POST "https://api.supabase.com/v1/projects/$PROJECT_REF/read-replicas/setup" \ -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "read_replica_region": "us-east-1" }' # Delete a Read Replica curl -X POST "https://api.supabase.com/v1/projects/$PROJECT_REF/read-replicas/remove" \ -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "database_identifier": "abcdefghijklmnopqrst" }'

创建请求发出后不代表副本立刻可用。Supabase 以物理备份为起点部署副本，再通过 WAL 文件档案加直接复制来追平 Primary。官方文档说明这两个阶段都可能耗时较长：恢复时间取决于数据库大小，追平时间取决于 Primary 的写入活跃度（写入越频繁，需要处理的 WAL 文件越多）。部署过程中 Dashboard 会展示进度和各阶段的粗略时间估计。

让读请求真正落到副本上

副本部署完成后，要降低跨区域读延迟还需要把应用指向正确的入口。Read Replicas 只读，能力边界如下：

（来源：Read Replicas）

文档给出的几种使用方式：

1. 专用端点：每个 Read Replica 有自己独立的数据库端点和 API 端点。数据库端点在项目Connect面板，通过Source下拉框在 Primary 与副本之间切换；API 端点在API Settings页的Project URL下，同样用Source下拉框切换。
2. REST API 只支持GET：通过副本的 API 端点只能发GET请求。如果通过 REST API 调用只读 Postgres 函数，需要设置get: true选项。
3. 注意产品边界：请求发往 Auth、Storage、Realtime 等其他 Supabase 产品时无法使用 Read Replica 及其 API 端点。所有 Auth 请求都由 Primary 处理，即使经过负载均衡器也是如此。
4. API 负载均衡器（推荐用于地理路由）：项目有一个自动在 Primary 与各副本之间均衡请求的负载均衡器，端点在API Settings页。它支持 geo-routing，自动把GET请求路由到离用户最近的数据库；非GET请求会自动路由回 Primary。2025 年 4 月 4 日起，符合条件的 Data API 请求从原来的 Round-Robin 分发改为 geo-routing，把副本部署在主要用户群附近可以最大化这个效果。两个例外要记住：使用自定义域名时请求不走负载均衡器，应改用 Dashboard 提供的专用端点；如果你之后删除了项目里所有 Read Replicas，负载均衡器会一并被移除，删除前需先把请求切回 Primary。
5. SQL editor：在 Studio 的 SQL 编辑器中可以指定让查询运行在某个 Read Replica 上。

验证部署结果：监控复制延迟

复制是异步的，Primary 上的变更到达副本之间存在 replication lag。文档提供了三种观察方式：

• 历史延迟：项目 Dashboard 的Database Reports页（Observability → Database），Read Replica 有一个Replica Information图表，以秒为单位展示历史复制延迟；
• 实时延迟：Infrastructure Settings页面上，Read Replica 条目上方显示的数值就是当前的实时复制延迟（秒）；
• 指标接入：如果你已把项目 metrics 接入自己的监控环境，可以用physical_replication_lag_physical_replica_lag_seconds指标跟踪复制延迟并设置告警。

官方文档明确说明：不存在一个统一的阈值来判断复制延迟何时需要处理，取决于项目自身的延迟要求，不要自行套用固定数值。

部署是否成功还有一个直接信号：副本在 Dashboard 中的状态。状态变为 "Init failed" 表示部署失败，处理方法见下节。

已知问题与操作限制

"Init failed" 状态：副本状态显示 "Init failed" 说明部署失败。文档列出的可能原因包括：底层实例未能启动、网络问题导致无法连接 Primary、Primary 与副本间存在不兼容的数据库配置、平台故障，以及高活跃负载叠加 50+ GB 的大数据库。处理建议：可以删除这个失败的副本并重试（偶发问题通常会成功）；但如果创建副本持续失败，先查看 Supabase 状态页是否有进行中的事件或提交支持工单，并且为了便于排查，此时不要删除那个刚失败的副本。

高复制延迟的常见来源：

1. Primary 上的表级排他锁：drop table、reindex等操作会对表加 access-exclusive lock，锁持有期间副本延迟上升；
2. 数据库资源受限：Primary 或副本资源占用过高（资源不足的项目尤甚），包括磁盘 IOPS、吞吐量特性；
3. Primary 上的长事务：可用pg_stat_activity视图识别并终止这类事务。注意pg_stat_activity是实时视图，不提供历史事务数据。

高复制延迟的直接后果是：在受影响副本上执行的查询可能返回过期数据。

被 Read Replicas 阻塞的操作：以下两类操作要求先把项目的全部 Read Replicas 下线，完成后再重新部署副本：

1. 项目升级（project upgrades，见 Upgrading）；
2. 数据恢复（PITR restoration）。

重启与变规格行为：重启使用 Read Replicas 的项目或变更计算规格时，Primary 会先重启，期间副本保持可用；Primary 完成重启（或变规格）后，所有副本并发重启（需要时同步变规格）。

收尾核对

完成本场景的判定标准可以落在这几件事上：Dashboard Infrastructure 页能看到目标区域的副本且状态正常（非 "Init failed"）；副本上方显示的实时复制延迟（秒）处于你可接受的水平；应用流量经由负载均衡器端点后，GET请求被路由到就近的数据库（副本侧可在 API Reports 页看到经由副本或负载均衡器的请求 metrics）。后续维护时记住两条硬约束：升级项目前先删副本、升级后重建；删除全部副本前先把请求切回 Primary。

【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase