监控管道状态

设置好 Supabase Pipelines 后，你可以直接在仪表板上监控管道的状态和健康情况。管道首先会对现有的行进行初始同步，然后使用持续复制（CDC）将后续的数据库更改发送到你的目标位置。

🌐 After setting up Supabase Pipelines, you can monitor the status and health of your pipelines directly from the Dashboard. A pipeline first performs an initial sync of existing rows, then uses ongoing replication (CDC) to send subsequent database changes to your destination.

查看管道状态 #

🌐 Viewing pipeline status

要监控你的管道：

🌐 To monitor your pipelines:

1. 导航到仪表板的 数据库 > 复制 部分
2. 你会看到所有目的地及其管道状态的列表

管道状态 #

🌐 Pipeline states

每个目的地都会显示其管道处于以下状态之一：

🌐 Each destination shows its pipeline in one of these states:

查看详细的流水线指标 #

🌐 Viewing detailed pipeline metrics

要查看特定管道的详细信息，请在目标上点击 查看管道。这会打开管道状态页面，你可以在这里监控复制性能和表的状态。

🌐 For detailed information about a specific pipeline, click View pipeline on the destination. This opens the pipeline status page where you can monitor replication performance and table states.

复制延迟指标 #

🌐 Replication lag metrics

状态页面显示复制延迟指标，帮助你判断流水线落后 Postgres 的程度。这些指标是直接从 Postgres 复制槽状态加载的。

🌐 The status page shows replication lag metrics that help you determine how far the pipeline is behind Postgres. These metrics are loaded directly from Postgres replication slot state.

目的地列表还显示了一个紧凑的延迟值。这个值是基于字节的：它显示管道还有多少 WAL 尚未确认已刷新。已追上 的值意味着管道已经确认了它的槽当前可用的每一个变化。

🌐 The destinations list also shows a compact lag value. This value is byte-based: it shows how much WAL the pipeline has not confirmed as flushed yet. A value of Caught up means the pipeline has confirmed every change currently available for its slot.

详细状态页面显示：

🌐 The detailed status page shows:

Pipelines使用一个主要的管道复制槽进行持续复制。在初始同步期间，它还可以创建临时的表同步复制槽。这些临时槽让多个表可以并行同步，使大型初始同步更快，并且允许单独的表在不重启整个管道的情况下重试。

🌐 Pipelines uses one main pipeline replication slot for ongoing replication. During the initial sync, it can also create temporary table-sync replication slots. These temporary slots let multiple tables sync in parallel, make large initial syncs faster, and allow individual tables to be retried without restarting the whole pipeline.

临时表同步槽在活跃时显示相同类型的延迟和槽健康指标。当表完成初始同步并赶上进度后，其临时槽会被移除，持续的复制通过主管道槽继续进行。对于整体复制健康状况，首先关注主管道槽。

🌐 Temporary table-sync slots show the same kind of lag and slot health metrics while they are active. After a table finishes its initial sync and catches up, its temporary slot is removed and ongoing replication continues through the main pipeline slot. For overall replication health, focus first on the main pipeline slot.

插槽状态 #

🌐 Slot statuses

复制槽状态告诉你 Postgres 是否还在保留管道继续从当前位置运行所需的 WAL。

🌐 Replication slot status tells you whether Postgres is still retaining the WAL that the pipeline needs to continue from its current position.

桌子上的状态 #

🌐 Table states

管道状态页面还会显示正在复制的各个表的状态。每个表可以处于以下状态之一：

🌐 The pipeline status page also shows the state of individual tables being replicated. Each table can be in one of these states:

处理复制延迟 #

🌐 Dealing with replication lag

复制延迟意味着管道落后于源数据库。在初次同步、写入高峰之后或重启已停止的管道后，一定程度的延迟是正常的。当延迟持续增加、WAL 保留时间快用完，或者槽位状态变为未保留或丢失时，延迟就会成为问题。

🌐 Replication lag means the pipeline is behind the source database. Some lag is expected during the initial sync, after a burst of writes, or after restarting a stopped pipeline. Lag becomes a problem when it keeps increasing, when WAL retention remaining is running low, or when the slot status moves to Unreserved or Lost.

延迟可能有好几个原因：

🌐 Lag can come from several places:

• 目标吞吐量：目标速度慢、有限速、不可用或拒绝写入。
• 管道吞吐量：管道超载了，正在处理一笔很大的交易，或者没有按照项目工作量的预期表现。
• 源数据库活动：Postgres 生成 WAL 的速度比管道能消耗的快，通常发生在批量写入、迁移或回填作业时。
• 网络延迟：管道与源数据库之间的延迟或不稳定可能会减慢 WAL 流的速度。
• 已停止或断开的管道：当管道被停止、断开或失败时，Postgres 会为该槽保留 WAL，直到达到保留限制。
• 初始同步慢：如果现有行的复制速度比新变更写入该表的速度慢，临时表同步槽可能会落后。

初始同步和表同步槽 #

🌐 Initial sync and table-sync slots

一个常见的初始同步问题是，当一个大的或繁忙的表仍然处于复制中时，新行不断被插入或更新。临时的表同步槽会保留初始同步期间发生的更改。如果复制的速度比表的写入速度慢，槽可能会变为未保留，然后如果 Postgres 删除了同步仍需要的更改，就会变为丢失。

🌐 A common initial sync issue happens when a large or busy table is still in Copying while new rows keep being inserted or updated. The temporary table-sync slot retains changes that happen during the initial sync. If copying is too slow compared to the table's write rate, the slot can move to Unreserved and then Lost if Postgres removes changes the sync still needs.

当表同步槽丢失时，受影响的表需要重新运行其初始同步。调整复制设置，然后重试该表：

🌐 When a table-sync slot is lost, the affected table needs to run its initial sync again. Tune the copy settings, then retry the table:

• 当一个大表成为瓶颈时，可以增加 每个表的复制连接数。这样管道就可以通过多条源连接复制该表的块，直到源数据库、网络或目标成为限制为止。
• 当需要同时复制多张表时，增加 表同步工作线程。每个工作线程可以复制一张表，并且在初始同步期间，每个工作线程会使用一个额外的临时复制槽。
• 如果可能的话，在写入量较少的时间段进行初始同步，或者减少大量写入，直到表格变为实时。

当受影响的表完成复制并赶上进度后，临时槽就会被删除。然后表会继续通过主流水线复制槽。

🌐 After the affected table finishes copying and catches up, the temporary slot is deleted. The table then continues through the main pipeline replication slot.

调查延迟 #

🌐 Investigate the lag

1. 打开 数据库 > 复制 并查看目标的延迟列。
2. 点击 查看管道 并检查 等待同步、WAL 剩余保留、最后签到、已连接 和 插槽状态。
3. 检查表的状态。处于 正在复制 的表在初始同步赶上正在进行的更改时可能会产生暂时的延迟。如果表同步槽是 未保留 或 丢失，调整复制并行度并重试受影响表的初始同步。
4. 打开 日志 > 复制，查看目标错误、重试、速率限制、模式错误或重复重启情况。
5. 把延迟趋势和最近的数据库活动比较一下，比如导入、迁移、大量更新或长时间事务。

根据插槽状态来回应 #

🌐 Respond based on the slot status

降低未来延迟风险 #

🌐 Reduce future lag risk

• 保持发布内容集中在你在目的地需要的表格和操作上。
• 避免在源数据库仍在接收写入时长时间让管道停止运行。
• 尽量在流量较低的时间安排批量更新、导入和迁移。
• 对于 BigQuery，请确认服务账号权限、表要求和副本标识设置是否符合 BigQuery 目标指南。
• 如果初始同步是瓶颈，可以查看管道高级设置中的表同步工作线程和每表复制连接数。增加其中任何一个都可以使用更多的源数据库连接；增加表同步工作线程还可以使用更多的临时复制槽。

处理错误 #

🌐 Handling errors

错误可能发生在两个层面：每张表或每个流水线。

🌐 Errors can occur at two levels: per table or per pipeline.

表格错误 #

🌐 Table errors

在初始同步期间会发生表错误，并且会影响单个表。这些错误可以重试，而不需要停止整个管道。

🌐 Table errors occur during the initial sync and affect individual tables. These errors can be retried without stopping the entire pipeline.

查看表格错误详情：

1. 点击你的目标上的 查看管道
2. 查看表状态部分，以识别处于错误状态的表
3. 查看那个特定表的错误信息

从表格错误中恢复：

当一个表在初始同步时遇到错误，你可以重置表的状态。这会从头开始重新同步这个表。

🌐 When a table encounters an error during the initial sync, you can reset the table state. This restarts that table's initial sync from the beginning.

管道错误 #

🌐 Pipeline errors

在启动或持续复制过程中可能会出现管道错误，并影响整个管道。如果发生不可重试的管道级错误，整个管道会停止并进入失败状态，而不是默默跳过错误。

🌐 Pipeline errors can occur during startup or ongoing replication and affect the entire pipeline. If a non-retryable pipeline-level error occurs, the entire pipeline stops and enters a Failed state instead of silently skipping the failure.

查看管道错误详情：

1. 将鼠标悬停在目的地列表中的失败状态上，以查看快速错误摘要
2. 点击 查看管道 获取详细的错误信息
3. 导航到仪表板的 日志 > 复制 部分查看详细的错误日志

从管道错误中恢复：

要从管道错误中恢复，你需要：

🌐 To recover from a pipeline error, you'll need to:

1. 用错误详情和日志查找根本原因
2. 修复根本问题（例如，目标连接性、模式兼容性）
3. 从目标列表重新启动管道

查看日志 #

🌐 Viewing logs

查看你所有管道的详细日志：

🌐 To see detailed logs for all your pipelines:

1. 导航到仪表板的 日志 > 复制 部分
2. 从日志源过滤器中选择 Replication
3. 你可以看到你所有管道的日志

常见监控场景 #

🌐 Common monitoring scenarios

检查复制是否正常 #

🌐 Checking if replication is healthy

1. 导航到仪表板的 数据库 > 复制 部分
2. 确认你的目的地显示为“运行中”状态
3. 点击 查看管道 来检查复制延迟和表状态
4. 确保所有表格显示“在线”状态

调查错误 #

🌐 Investigating errors

如果你看到 失败 状态：

🌐 If you see a Failed status:

1. 将鼠标悬停在状态上查看错误摘要
2. 点击 查看流水线 查看详细的错误信息
3. 检查表状态，找出哪些表受影响
4. 导航到仪表板的 日志 > 复制 部分查看完整的错误详情
5. 对于表格错误，尝试重置受影响的表格

监控性能 #

🌐 Monitoring performance

为确保最佳性能：

🌐 To ensure optimal performance:

1. 经常在管道状态视图中查看复制延迟指标
2. 监控表的状态，确保表保持在“活动”状态
3. 查看日志，看看有没有警告或性能问题
4. 如果延迟一直很高，检查一下你的发布和目标配置

故障排除 #

🌐 Troubleshooting

如果你发现你的复制有问题：

🌐 If you notice issues with your replication:

1. 检查管道状态：确保管道处于运行中状态
2. 审查表状态：识别处于错误状态的表
3. 查看日志：前往仪表板的 日志 > 复制 部分获取详细的错误信息
4. 验证发布：确保你的 Postgres 发布已正确配置
5. 监控复制延迟：高延迟可能表明性能问题

想要更多故障排除技巧，请查看 Pipelines 常见问题。

🌐 For more troubleshooting tips, see the Pipelines FAQ.

下一步 #

🌐 Next steps

• 设置管道
• 查看管道常见问题