管道常见问题
Common questions and answers about Supabase Pipelines.
公开测试版
Supabase Pipelines 目前处于公开测试阶段。随着我们继续开发产品，功能和表现可能会有所变化。
🌐 Supabase Pipelines is currently in public alpha. Features and behavior may change as we continue developing the product.
哪些计划支持Pipelines？ #
🌐 Which plans support Pipelines?
流水线需要 Pro、Team 或 Enterprise 计划。在公开测试阶段，可用性因组织而异；即使计划符合条件，也不保证能访问。如果无法使用，可以通过 Database > Pipelines 请求访问，或者联系你的客户经理。
🌐 Pipelines requires a Pro, Team, or Enterprise plan. During public alpha, availability varies by organization; an eligible plan does not guarantee access. If unavailable, request access from Database > Pipelines or contact your account manager.
支持哪些目的地？ #
🌐 What destinations are supported?
BigQuery、ClickHouse、DuckLake 和 Snowflake 都处于公开测试阶段。有关设置指南，请参见 支持的目标。
🌐 BigQuery, ClickHouse, DuckLake, and Snowflake are in public alpha. For setup guides, see supported destinations.
目的地的区域会影响性能吗？ #
🌐 Does the destination's region affect performance?
是的。源头、管道和目标之间的距离会增加网络延迟，并可能降低吞吐量。如果只能优化一端，优先选择接近目标的资源，同时尽量选择靠近托管管道区域的资源。
🌐 Yes. Distance between the source, pipeline, and destination adds network latency and can reduce throughput. Choose resources near the managed pipeline region, prioritizing the destination if you can optimize only one side.
Pipelines 在数据库里安装什么？ #
🌐 What does Pipelines install in the database?
Pipelines 在你项目的 Postgres 数据库中安装对象，用来跟踪复制并支持架构更改：
🌐 Pipelines installs objects in your project's Postgres database to track replication and support schema changes:
- 一个
etl架构，包含用于复制状态和进度的内部表、源表架构、目标映射以及迁移历史。 etl中的辅助函数，用于读取表定义并准备模式更改消息。- 一个数据库事件触发器
supabase_etl_ddl_message_trigger，在ALTER TABLE和ALTER PUBLICATION之后运行。它将已发布表的模式更改信息写入预写日志（WAL），这样 Pipelines 就可以和行更改一起处理支持的更改。
每个管道还使用复制槽来跟踪它在 WAL 中的位置。参见 初始同步和表同步槽 了解这些在复制过程中如何保留更改。
🌐 Each pipeline also uses replication slots to track its position in WAL. See initial sync and table-sync slots for how these retain changes during replication.
etl 模式是为 Pipelines 保留的。如果你的应用已经使用了名为 etl 的模式，请在启用 Pipelines 之前重命名它并更新对它的引用。不要将应用对象添加到由 Pipelines 管理的模式中，也不要将其包含在发布中。
🌐 The etl schema is reserved for Pipelines. If your application already uses a schema named etl, rename it and update references to it before enabling Pipelines. Do not add application objects to the Pipelines-managed schema or include it in a publication.
要删除已安装的对象，先删除所有管道，然后禁用管道。
🌐 To remove the installed objects, delete all pipelines, then disable Pipelines.
在创建管道之前，Pipelines 会检查什么？ #
🌐 What does Pipelines check before creating a pipeline?
仪表板会验证源访问、复制容量、发布表以及目标的连接性和需求。必填问题会阻止创建；警告需要审核。请参阅创建检查。
🌐 The Dashboard validates source access, replication capacity, publication tables, and destination connectivity and requirements. Required issues block creation; Warnings require review. See creation checks.
支持哪些模式更改？ #
🌐 What schema changes are supported?
支持因目的地而异。在更改列类型、默认值、键或约束之前，请查看模式更改指南。
🌐 Support differs by destination. Check the schema-change guides before changing column types, defaults, keys, or constraints.
数据可以被处理不止一次吗？ #
🌐 Can data be processed more than once?
是的。Pipelines 提供至少一次处理：恢复可以重放已确认的数据，而只追加的历史数据的消费者必须能容忍重复的事件。目标去重并不能保证严格的一次处理。
🌐 Yes. Pipelines provides at-least-once processing: recovery can replay acknowledged data, and consumers of append-only histories must tolerate repeated events. Destination deduplication does not provide an exactly-once processing guarantee.
查看 BigQuery、ClickHouse、DuckLake 和 Snowflake 的数据模型，以及 计费影响。
🌐 See the data models for BigQuery, ClickHouse, DuckLake, and Snowflake, and the billing implications.
为什么这张表没有被复制？ #
🌐 Why is a table not being replicated?
检查一下：
🌐 Check that:
如果有新的更改到来，但现有的行丢失了，请检查初始同步选择。更改行过滤器也不会复制新包含的历史行。
🌐 If new changes arrive but existing rows are missing, check the initial sync selection. Changing a row filter also does not copy newly included historical rows.
如果插入操作有效，但更新或删除操作失败，请查看 BigQuery、ClickHouse、DuckLake 或 Snowflake 的源表要求。
🌐 If inserts work but updates or deletes fail, review the source table requirements for BigQuery, ClickHouse, DuckLake, or Snowflake.
为什么表格会处于错误状态？ #
🌐 Why is a table in error state?
初次同步或正在进行的复制操作失败，例如在不支持的模式更改之后。有些错误会自动重试；其他错误则需要从头重新启动受影响表的复制。请参阅 表错误 进行诊断，以及 重新启动表 了解操作步骤及其影响。
🌐 An initial sync or ongoing replication operation failed, for example after an unsupported schema change. Some errors retry automatically; others require restarting replication for the affected tables from scratch. See Table errors for diagnosis and Restarting tables for the procedure and its effects.
为什么管道失败或停止了？ #
🌐 Why is a pipeline failed or stopped?
失败 表示启动或运行时出错，并且可以自动恢复。已停止 需要手动启动。请按照 流水线错误恢复 来诊断原因，然后再重启。
为什么复制延迟在增加？ #
🌐 Why is replication lag increasing?
Postgres 生成 WAL 的速度比 Pipelines 确认进度的速度快。按照 调查延迟 来区分源活动、目标吞吐量和连接问题。
🌐 Postgres is producing WAL faster than Pipelines confirms progress. Follow Investigate the lag to distinguish source activity, destination throughput, and connectivity problems.
Lost#
🌐 What does a Lost slot status mean?
所需的 WAL 已经丢失，所以无法从该槽继续复制。请参考 槽恢复；恢复范围取决于丢失的是主槽还是表同步槽。
🌐 Required WAL is gone, so replication cannot continue from that slot. Follow slot recovery; recovery scope depends on whether the main slot or a table-sync slot was lost.
如果目标处的表被删除会发生什么？ #
🌐 What happens if a table is deleted at the destination?
删除或修改托管对象可能会停止复制，并需要新的初始同步。要安全地删除它，先从发布中移除源表，然后在删除目标表之前重启管道。
🌐 Deleting or modifying managed objects can stop replication and require a new initial sync. To remove one safely, remove the source table from the publication and restart the pipeline before deleting its destination table.
当一个项目变得不活跃或转到免费计划时会发生什么？ #
🌐 What happens when a project becomes inactive or moves to the Free Plan?
项目不活跃会停止它的流水线。重启项目后手动启动它们。降级到免费计划会删除它的流水线。
🌐 Project inactivity stops its pipelines. Start them manually after restarting the project. Downgrading to the Free Plan deletes its pipelines.
禁用管道会发生什么？ #
🌐 What happens when you disable Pipelines?
禁用管道会移除其数据库事件触发器以及整个由管道管理的 etl 架构，包括其表和辅助函数。你的源应用表和现有目标数据会保留。
🌐 Disabling Pipelines removes its database event trigger and the entire Pipelines-managed etl schema, including its tables and helper functions. Your source application tables and existing destination data remain.
先删除所有管道，然后按照 禁用管道 操作。仅删除管道并不会移除共享数据库安装。
🌐 Delete all pipelines first, then follow Disabling Pipelines. Deleting the pipelines alone does not remove the shared database installation.