开始使用只读副本

Deploy read-only databases across multiple regions, for lower latency and better resource management.

先决条件 #

🌐 Prerequisites

所有使用 Pro、Team 和 Enterprise 计划的项目都可以使用只读副本。现在就去基础设施设置页面创建一个吧。

🌐 Read Replicas are available for all projects on the Pro, Team and Enterprise plans. Spin one up now over at the Infrastructure Settings page.

项目必须满足这些要求才能使用只读副本：

🌐 Projects must meet these requirements to use Read Replicas:

运行在 AWS 上。
至少运行在一个小型计算附加组件上。
- 只读副本在与主实例相同的计算实例上启动，以跟上更改。
运行在 Postgres 15 及以上版本。
- 对于运行在较旧版本 Postgres 上的项目，你需要升级到最新的平台版本。
不使用传统逻辑备份
- 如果使用时间点恢复 (PITR)，物理备份会自动启用

创建只读副本 #

🌐 Creating a Read Replica

要添加只读副本，请转到你项目仪表板中的基础设施设置页面。

🌐 To add a Read Replica, go to the Infrastructure settings page in your project dashboard.

你也可以使用管理 API（测试功能）来管理只读副本：

🌐 You can also manage Read Replicas using the Management API (beta functionality):

1
# Get your access token from https://supabase.nodejs.cn/dashboard/account/tokens
2
export SUPABASE_ACCESS_TOKEN="your-access-token"
3
export PROJECT_REF="your-project-ref"
4
5
# Create a new Read Replica
6
curl -X POST "https://api.supabase.com/v1/projects/$PROJECT_REF/read-replicas/setup" \
7
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
8
  -H "Content-Type: application/json" \
9
  -d '{
10
    "read_replica_region": "us-east-1"
11
  }'
12
13
# Delete a Read Replica
14
curl -X POST "https://api.supabase.com/v1/projects/$PROJECT_REF/read-replicas/remove" \
15
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
16
  -H "Content-Type: application/json" \
17
  -d '{
18
    "database_identifier": "abcdefghijklmnopqrst"
19
  }'

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

🌐 Projects on an XL compute add-on or larger can create up to five Read Replicas. Projects on compute add-ons smaller than XL can create up to two Read Replicas. All Read Replicas inherit the compute size of their Primary database.

部署只读副本 #

🌐 Deploying a Read Replica

我们使用物理备份作为起点来部署只读副本，并结合使用预写日志（WAL）文件归档和从主数据库直接复制来追赶更新。两部分可能都需要相当长的时间才能完成，这取决于你的具体工作负载。

🌐 We deploy a Read Replica using a physical backup as a starting point, and a combination of write ahead logging (WAL) file archives and direct replication from the Primary database to catch up. Both components may take significant time to complete, depending on your specific workload.

从物理备份恢复的时间取决于你的项目数据库的大小。使用 WAL 存档和直接复制赶上主库所需的时间取决于主数据库的活动水平。活动越频繁的数据库会产生更多需要处理的 WAL 文件。

🌐 The time to restore from a physical backup is dependent and directly related to the database size of your project. The time taken to catch up to the primary using WAL archives and direct replication is dependent on the level of activity on the Primary database. A more active database produces a larger number of WAL files that need to be processed.

随着部署的进展，仪表板会显示每个组件的大概估算。

🌐 Along with the progress of the deployment, the dashboard displays rough estimates for each component.

复制方法详情 #

🌐 Replication method details

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

🌐 We use a hybrid approach to replicate data from a Primary to its Read Replicas, combining the native methods of streaming replication and file-based log shipping.

流式复制 #

🌐 Streaming replication

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

🌐 Postgres generates a Write Ahead Log (WAL) as database changes occur. With streaming replication, these changes stream from the Primary to the Read Replica server. The WAL alone is sufficient to reconstruct the database to its current state.

这种复制方法很快，因为主库的变更会直接传到只读副本。不过，当只读副本跟不上来自主库的 WAL 变更时，会面临一些问题。这种情况可能发生在只读副本太小、运行在性能下降的硬件上，或者有更重的工作负载时。

🌐 This replication method is fast, since the Primary streams changes directly to the Read Replica. However, it faces challenges when the Read Replica can't keep up with the WAL changes from its Primary. This can happen when the Read Replica is too small, running on degraded hardware, or has a heavier workload running.

为了解决这个问题，Postgres 提供了可调的配置，比如 wal_keep_size，用于调整主库保留的 WAL。如果只读副本在 WAL 超过 wal_keep_size 设置之前没有“追上”，复制就会终止。调优是一门艺术——每种情况所需的 WAL 数量都不一样。

🌐 To address this, Postgres provides tunable configuration, like wal_keep_size, to adjust the WAL retained by the Primary. If the Read Replica fails to "catch up" before the WAL surpasses the wal_keep_size setting, it terminates the replication. Tuning is an art - the amount of WAL required varies for every situation.

基于文件的日志传输 #

🌐 File-based log shipping

在这种复制方法中，主节点会持续将 WAL 变更缓存到本地文件，然后将文件发送给只读副本。如果存在多个只读副本，文件也可以发送到所有副本都能访问的中间位置。

🌐 In this replication method, the Primary continuously buffers WAL changes to a local file and then sends the file to the Read Replica. If multiple Read Replicas are present, files could also be sent to an intermediary location accessible by all replicas.

读副本随后会读取 WAL 文件并应用这些更改。因为主节点会先在本地缓冲更改，所以复制延迟比流复制要高。这也意味着如果主节点在文件传输前宕机，WAL 的更改有可能无法到达读副本。在这种情况下，如果主节点发生故障，使用流复制的副本（大多数情况下）会比使用基于文件的日志传输的副本更新一些。

🌐 The Read Replica then reads the WAL files and applies those changes. There is higher replication lag than streaming replication since the Primary buffers the changes locally first. It also means there is a small chance that WAL changes do not reach Read Replicas if the Primary goes down before the file is transferred. In these cases, if the Primary fails a Replica using streaming replication would (in most cases) be more up-to-date than a Replica using file-based log shipping.

基于文件的日志传输遇上流复制 #

🌐 File-based log shipping meets streaming replication

Map view of Primary and Read Replica databases

我们将这两种方法结合起来，实现快速、稳定且可靠的复制。每种方法都能弥补另一种方法的不足。流复制可以最大限度地减少复制延迟，而基于文件的日志传送则提供一种备用方案。对于基于文件的日志传送，我们使用现有的时间点恢复（PITR）基础设施。我们会定期使用 WAL-G —— 一个开源的归档和恢复工具 —— 从主服务器归档文件，并将 WAL 文件发送到异地的持久化云存储，例如 S3。

🌐 We bring these two methods together to achieve quick, stable, and reliable replication. Each method addresses the limitations of the other. Streaming replication minimizes replication lag, while file-based log shipping provides a fallback. For file-based log shipping, we use our existing Point In Time Recovery (PITR) infrastructure. We regularly archive files from the Primary using WAL-G, an open source archival and restoration tool, and ship the WAL files to off-site, durable cloud storage, such as S3.

我们把它和流复制结合起来以减少复制延迟。一旦 WAL-G 文件从 S3 同步完成，读取副本就会连接到主库并直接流式传输 WAL。

🌐 We combine it with streaming replication to reduce replication lag. Once WAL-G files have been synced from S3, Read Replicas connect to the Primary and stream the WAL directly.

重新启动或计算插件更改的行为 #

🌐 Restart or compute add-on change behaviour

当你重新启动使用只读副本的项目，或者更改计算附加组件的大小时，主数据库会先被重启。在此期间，只读副本仍然可用。

🌐 When you restart a project that uses Read Replicas, or change the compute add-on size, the Primary database gets restarted first. During this period, the Read Replicas remain available.

一旦主数据库完成重启（或在计算附加更改的情况下调整大小）并可以使用，所有只读副本都会同时重启（如有需要，也会调整大小）。

🌐 Once the Primary database has completed restarting (or resizing, in case of a compute add-on change) and become available for usage, all the Read Replicas are restarted (and resized, if needed) concurrently.

操作被只读副本阻止 #

🌐 Operations blocked by Read Replicas

项目升级和数据恢复 #

🌐 Project upgrades and data restorations

以下操作需要在执行之前关闭项目的所有只读副本：

🌐 The following procedures require all Read Replicas for a project to be brought down before performing them:

在你重新部署只读副本之前，这些操作需要先完成。

🌐 These operations need to complete before you can re-deploy Read Replicas.

监控复制延迟 #

🌐 Monitoring replication lag

你可以通过项目仪表板在数据库报告页面监控特定只读副本的复制延迟。只读副本在副本信息下还有一个额外的图表，显示历史复制延迟（以秒为单位）。

🌐 You can monitor replication lag for a specific Read Replica through a project dashboard on the Database Reports page. Read Replicas have an additional chart under Replica Information displaying historical replication lag in seconds.

你可以在基础设施设置页面看到实时复制延迟（以秒为单位）。这个值显示在只读副本的顶部。

🌐 You can see realtime replication lag in seconds on the Infrastructure Settings page. This is the value on top of the Read Replica.

没有一个明确的阈值可以说明你什么时候应该处理复制延迟。这取决于你项目的要求。

🌐 There is no single threshold to indicate when you should address replication lag. It is dependent on the requirements of your project.

如果你已经在自己的环境中获取你的项目指标，你也可以通过physical_replication_lag_physical_replica_lag_seconds指标跟踪复制延迟并设置警报。

🌐 If you are already ingesting your project's metrics into your own environment, you can also keep track of replication lag and set alarms with the physical_replication_lag_physical_replica_lag_seconds metric.

解决高复制延迟 #

🌐 Addressing high replication lag

高复制延迟的一些常见原因包括：

🌐 Some common sources of high replication lag include:

主库上的表的排他锁：像 drop table 和 reindex 这样的操作会对表加上访问排他锁。这可能会导致在锁存在期间复制延迟增加。
数据库的资源限制：如果在资源不足的项目上运行，主数据库或副本的高负载可能会导致复制延迟变高。这还包括所用磁盘的特性（IOPS，吞吐量）。
主库上的长时间运行事务：在主库上运行很久的事务也可能导致高复制延迟。你可以使用 pg_stat_activity 视图来识别并在必要时终止这些事务。pg_stat_activity 是一个实时视图，无法提供过去可能长期存在的事务的历史数据。高复制延迟可能导致针对受影响的只读副本执行的查询返回过时的数据。

你可以在谷歌文档、AWS 文档以及Several Nines 博客中找到关于复制延迟的更多资源。

🌐 You can find additional resources on replication lag in the Google documentation, the AWS documentation, and the several nines blog.

故障排除 #

🌐 Troubleshooting

“初始化失败”状态 #

🌐 An "Init failed" status

仪表板中副本状态“初始化失败”表示只读副本部署失败。只读副本部署可能失败的一些情况如下：

🌐 The replica status "Init failed" in the dashboard indicates that the Read Replica has failed to deploy. Some possible scenarios as to why a Read Replica deployment may have failed are the following:

一个底层实例未能启动。
网络问题导致无法连接到主数据库。
主数据库和只读副本数据库之间可能存在不兼容的数据库设置。
平台问题。
非常高的活跃工作负载加上大型（50GB以上）数据库

可以安全地删除这个失败的只读副本，如果只是暂时性问题，可以尝试再启动一个。如果你项目的只读副本总是启动失败，可以查看状态页面了解是否有正在进行的事件，或者提交支持请求。为了帮助调查，请不要关闭最近失败的只读副本。

🌐 It is safe to drop this failed Read Replica, and in the event of a transient issue, attempt to spin up another one. If spinning up Read Replicas for your project consistently fails, check thestatus page for any ongoing incidents, or open a support ticket. To aid the investigation, do not bring down the recently failed Read Replica.