数据库复制
An introduction to database replication and change data capture.
复制可以让数据与另一个位置保持同步。像 Supabase Pipelines 这样的逻辑复制产品使用变更数据捕获(CDC)来读取数据库的更改,并将其应用到目标位置。
🌐 Replication keeps data synchronized with another location. Logical replication products such as Supabase Pipelines use change data capture (CDC) to read database changes and apply them to a destination.
用例 #
🌐 Use cases
你可能会用数据库复制来做:
🌐 You might use database replication for:
- 分析与数据仓储:将你的运营数据库复制到分析平台,进行复杂分析,同时不影响应用性能。
- 数据整合:让你的数据在技术栈的不同系统和服务之间保持同步。
- 操作报告:保留一份所选应用数据的副本,以便你可以在另一个系统中查询。
复制方法 #
🌐 Replication methods
Supabase 支持三种复制方式。你可以根据自己是否需要另一个 Supabase Postgres 数据库、一个到目标系统的托管复制管道,或者对自己的逻辑复制设置有完全控制来选择。
🌐 Supabase supports three replication methods. Choose based on whether you need another Supabase Postgres database, a managed replication pipeline to a destination system, or full control over your own logical replication setup.
阅读副本 #
🌐 Read replicas
只读副本是额外的 Supabase Postgres 数据库,与主数据库保持同步。当你想要只读查询能力、在其他地区降低延迟,或者在仍然使用 Supabase Postgres 的情况下,将分析读取与应用写入隔离开时,可以使用它们。
🌐 Read replicas are additional Supabase Postgres databases kept in sync with your primary database. Use them when you want read-only query capacity, lower latency in another region, or to isolate analytical reads from application writes while staying inside Supabase Postgres.
- [设置已读复制品](/docs/guides/platform/read-replicas)
管道 #
🌐 Pipelines
公开测试版
Supabase Pipelines 目前处于公开测试阶段。随着我们继续开发产品,功能和表现可能会有所变化。
🌐 Supabase Pipelines is currently in public alpha. Features and behavior may change as we continue developing the product.
Supabase Pipelines 是一个托管的 CDC 产品,用于将数据从 Supabase Postgres 移动到支持的目标系统。它使用 Postgres 的逻辑复制和开源的 Supabase ETL 引擎。目的地是存储你复制数据的地方;管道首先会对现有行进行初始同步,然后使用持续复制(CDC)将后续的数据库更改发送到该目的地。
🌐 Supabase Pipelines is a managed CDC product for moving data from Supabase Postgres to supported destination systems. It uses Postgres logical replication with the open-source Supabase ETL engine. A destination is where your replicated data is stored; a pipeline first performs an initial sync of existing rows, then uses ongoing replication (CDC) to send subsequent database changes to that destination.
支持的目的地 #
🌐 Supported destinations
Pipelines 目前支持 BigQuery 作为管理目标。你可以在我们扩展目标支持的同时,申请提前使用 ClickHouse、Snowflake 和 DuckLake。
🌐 Pipelines currently supports BigQuery as the managed destination. You can request early access to ClickHouse, Snowflake, and DuckLake while we expand destination support.
托管管道运行在 AWS eu-central-1(法兰克福)。选择尽可能靠近法兰克福的目标资源,以减少网络延迟和复制延迟。
🌐 Managed Pipelines run in AWS eu-central-1 (Frankfurt). Choose destination resources as close as possible to Frankfurt to reduce network latency and replication lag.
| 目标 | 插入 | 更新 | 删除 | 截断 | 架构变更 | 描述 |
|---|---|---|---|---|---|---|
| BigQuery | ✅ 支持 | ✅ 支持 | ✅ 支持 | ✅ 支持 | 测试版(有限) | 管理式复制到 Google BigQuery,用于分析和报告。 |
手动复制 #
🌐 Manual replication
手动复制使用与管道相同的底层 Postgres 逻辑复制功能,但你需要自己配置和操作各个部分。当你想要连接像 Airbyte、Estuary、Fivetran、Materialize、Stitch、AWS DMS 或其他支持 Postgres 逻辑复制的系统时,可以使用这种方式。
🌐 Manual replication uses the same underlying Postgres logical replication features as Pipelines, but you configure and operate the pieces yourself. Use this path when you want to connect tools such as Airbyte, Estuary, Fivetran, Materialize, Stitch, AWS DMS, or another system that supports Postgres logical replication.
相关功能 #
🌐 Related features
有关实时功能以及将数据同步到客户端(浏览器、移动应用),请参见 Realtime。
🌐 For realtime features and syncing data to clients (browsers, mobile apps), see Realtime.
实时功能也使用 Postgres 变化,但它是用于将数据库更新广播给客户端,而不是在另一个系统中维护数据库的副本。
🌐 Realtime also uses Postgres changes, but it is intended for broadcasting database updates to clients rather than maintaining a copy of your database in another system.
概念和术语 #
🌐 Concepts and terms
预写日志 (WAL) #
🌐 Write-Ahead Log (WAL)
Postgres 使用一种叫做预写日志(WAL)的系统来管理数据库的更改。当你进行修改时,这些修改会被追加到 WAL 中,WAL 是一系列文件(也叫“段”),文件大小可以指定。一旦一个段满了,Postgres 就会开始追加到一个新的段。过一段时间后,会发生检查点操作,Postgres 会将 WAL 与你的数据库同步。一旦检查点完成,WAL 文件就可以从磁盘中删除,从而释放空间。
🌐 Postgres uses a system called the Write-Ahead Log (WAL) to manage changes to the database. As you make changes, they are appended to the WAL, which is a series of files (also called "segments") where the file size can be specified. Once one segment is full, Postgres will start appending to a new segment. After a period of time, a checkpoint occurs and Postgres synchronizes the WAL with your database. Once the checkpoint is complete, then the WAL files can be removed from disk and free up space.
逻辑复制和WAL #
🌐 Logical replication and WAL
逻辑复制是一种复制方法,Postgres 使用 WAL 文件将更改传输到另一个 Postgres 数据库,或者传输到支持读取 WAL 文件的系统。
🌐 Logical replication is a method of replication where Postgres uses WAL files to transmit changes to another Postgres database, or to a system that supports reading WAL files.
LSN#
LSN 是日志序列号,用来标识 WAL 中的位置。它通常用来确定订阅者的复制进度,以及计算复制槽的延迟。
🌐 LSN is a Log Sequence Number that identifies a position in the WAL. It is often used to determine the progress of replication in subscribers and calculate the lag of a replication slot.
逻辑复制架构 #
🌐 Logical replication architecture
在设置逻辑复制时,涉及三个关键组件:
🌐 When setting up logical replication, three key components are involved:
publication- 你主数据库里的一组表将会是publishedreplication slot- 一个用于复制单个发布数据的插槽。创建插槽时,会指定更改的输出格式。subscription- 订阅是从外部系统(也就是另一个 Postgres 数据库)创建的,并且必须指定publication的名称。如果你没有指定复制槽,系统会自动创建一个
逻辑复制输出格式 #
🌐 Logical replication output format
逻辑复制通常有两种输出形式,pgoutput 和 wal2json。输出方式就是 Postgres 向任何活动的复制槽发送更改的方式。
🌐 Logical replication is typically output in two forms, pgoutput and wal2json. The output method is how Postgres sends changes to any active replication slot.
逻辑复制配置 #
🌐 Logical replication configuration
在使用逻辑复制时,Postgres 会比平常更长时间保留 WAL 文件。如果文件被过早删除,那么如果数据库在短时间内接收到大量更改,你的 replication slot 可能会变得不活跃或丢失。
🌐 When using logical replication, Postgres keeps WAL files around for longer than it otherwise needs them. If the files are removed too soon, then your replication slot can become inactive or lost if the database receives a large number of changes in a short time.
为了缓解这个问题,Postgres 有许多选项和设置可以调整来有效管理 WAL 的使用。不过,并非所有这些设置都能由用户配置,因为它们可能影响数据库的稳定性。对于那些可以配置的设置,应视为高级配置,只有在理解它们可能会占用额外磁盘空间和资源,并产生额外成本的前提下才进行更改。
🌐 In order to mitigate this, Postgres has many options and settings that can be tweaked to manage the WAL usage effectively. Not all of these settings are user configurable as they can impact the stability of your database. For those that are, these should be considered as advanced configuration and not changed without understanding that they can cause additional disk space and resources to be used, as well as incur additional costs.
| 设置 | 描述 | 面向用户 | 默认值 |
|---|---|---|---|
max_replication_slots | 允许的复制槽最大数量 | 否 | |
wal_keep_size | 为复制保留的 WAL 文件最小大小 | 否 | |
max_slot_wal_keep_size | 复制槽可以保留的最大 WAL 大小 | 否 | |
checkpoint_timeout | WAL 检查点之间的最长时间 | 否 |