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付费计划Read Replicas 仅对 Pro、Team 和 Enterprise 计划的所有项目可用。运行在 AWS 上项目必须部署在 AWS。至少 Small 计算规格Read Replicas 启动在与 Primary 相同的计算实例上以跟上数据变化。Small 及以下的规格含 Micro、Nano不满足要求。具体规格可参考 Compute and Disk。Postgres 15 及以上运行旧版 Postgres 的项目需要先升级到最新平台版本。未使用 legacy logical backups使用 Point in Time RecoveryPITR的项目会自动启用物理备份因此不受影响参见 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_TOKENyour-access-token export PROJECT_REFyour-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 只读能力边界如下selectinsertupdatedeletePrimary✅✅✅✅Read Replica✅---来源Read Replicas文档给出的几种使用方式专用端点每个 Read Replica 有自己独立的数据库端点和 API 端点。数据库端点在项目Connect面板通过Source下拉框在 Primary 与副本之间切换API 端点在API Settings页的Project URL下同样用Source下拉框切换。REST API 只支持GET通过副本的 API 端点只能发GET请求。如果通过 REST API 调用只读 Postgres 函数需要设置get: true选项。注意产品边界请求发往 Auth、Storage、Realtime 等其他 Supabase 产品时无法使用 Read Replica 及其 API 端点。所有 Auth 请求都由 Primary 处理即使经过负载均衡器也是如此。API 负载均衡器推荐用于地理路由项目有一个自动在 Primary 与各副本之间均衡请求的负载均衡器端点在API Settings页。它支持 geo-routing自动把GET请求路由到离用户最近的数据库非GET请求会自动路由回 Primary。2025 年 4 月 4 日起符合条件的 Data API 请求从原来的 Round-Robin 分发改为 geo-routing把副本部署在主要用户群附近可以最大化这个效果。两个例外要记住使用自定义域名时请求不走负载均衡器应改用 Dashboard 提供的专用端点如果你之后删除了项目里所有 Read Replicas负载均衡器会一并被移除删除前需先把请求切回 Primary。SQL editor在 Studio 的 SQL 编辑器中可以指定让查询运行在某个 Read Replica 上。验证部署结果监控复制延迟复制是异步的Primary 上的变更到达副本之间存在 replication lag。文档提供了三种观察方式历史延迟项目 Dashboard 的Database Reports页Observability → DatabaseRead 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 状态页是否有进行中的事件或提交支持工单并且为了便于排查此时不要删除那个刚失败的副本。高复制延迟的常见来源Primary 上的表级排他锁drop table、reindex等操作会对表加 access-exclusive lock锁持有期间副本延迟上升数据库资源受限Primary 或副本资源占用过高资源不足的项目尤甚包括磁盘 IOPS、吞吐量特性Primary 上的长事务可用pg_stat_activity视图识别并终止这类事务。注意pg_stat_activity是实时视图不提供历史事务数据。高复制延迟的直接后果是在受影响副本上执行的查询可能返回过期数据。被 Read Replicas 阻塞的操作以下两类操作要求先把项目的全部 Read Replicas 下线完成后再重新部署副本项目升级project upgrades见 Upgrading数据恢复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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考