监控管道状态

使用仪表板来查看复制进度、调查滞后和从错误中恢复。

🌐 Use the Dashboard to check replication progress, investigate lag, and recover from errors.

查看管道状态 #

🌐 Viewing pipeline status

打开 数据库 > 管道 查看每个目标的管道状态。

🌐 Open Database > Pipelines to see each destination's pipeline status.

管道状态 #

🌐 Pipeline states

运行中 并不能确认初始同步已经完成，源端是否已连接，或目标端的写入是否完成。查看表状态和延迟来评估进度。

查看详细的流水线指标 #

🌐 Viewing detailed pipeline metrics

点击列表中的一个管道来查看它的指标和表状态。

🌐 Click a pipeline in the list to inspect its metrics and table states.

桌子上的状态 #

🌐 Table states

复制延迟指标 #

🌐 Replication lag metrics

这些指标来自 Postgres 复制槽状态。管道列表还显示一个基于字节的延迟值：Caught up（已追赶） 意味着在测量时确认的刷新位置和当前 WAL 位置之间没有差距。这并不保证每个表都完成了初始同步，也不保证数据对目标查询可见。

🌐 These metrics come from Postgres replication slot state. The pipeline list also shows a byte-based lag value: Caught up means no gap between the confirmed flush position and current WAL position at measurement time. It does not guarantee that every table has finished initial sync or that data is visible to destination queries.

当 Postgres 没有返回 safe_wal_size 时，仪表板会显示 无限。这种情况既会在无限保留时发生，也会在 丢失 插槽时发生，所以一定要检查插槽状态。参见 Postgres 复制插槽指标。

🌐 The Dashboard displays Unlimited when Postgres returns no safe_wal_size. That happens both with unlimited retention and with a Lost slot, so always check slot status. See Postgres replication slot metrics.

在写入缓慢和 WAL 读取暂停的时候，Pipelines 会一直发送反馈。它会重复上一个安全位置，却不会确认未完成的写入。因此，最近的检入和一个活跃的连接可以与不断增长的延迟共存。

🌐 Pipelines keeps sending feedback during slow writes and while WAL reading is paused. It repeats the last safe position without acknowledging unfinished writes. A recent check-in and an active connection can therefore coexist with growing lag.

主槽跟踪正在进行的复制。表同步槽 会在初始同步期间暂时出现，并具有相同的指标。

🌐 The main slot tracks ongoing replication. Table-sync slots appear temporarily during initial sync and have the same metrics.

插槽状态 #

🌐 Slot statuses

查看 根据插槽状态响应 以获取恢复操作。

🌐 See Respond based on the slot status for recovery actions.

查看日志 #

🌐 Viewing logs

打开 日志 > 复制 查看错误、重试和性能警告。联系 支持 时请包含管道 ID 和相关错误信息。

🌐 Open Logs > Replication for errors, retries, and performance warnings. Include the pipeline ID and relevant errors when contacting support.

处理错误 #

🌐 Handling errors

表格错误可能会暂停某个表格，而其他表格继续复制。管道错误会影响整个流程。

🌐 Table errors can pause one table while others continue replicating. Pipeline errors affect the overall process.

表格错误 #

🌐 Table errors

打开管道，检查表错误和任何计划的重试，并修复原因。如果复制无法从保存的状态安全恢复，重新启动受影响表的复制。

🌐 Open the pipeline, inspect the table error and any scheduled retry, and fix the cause. If replication cannot safely resume from its saved state, restart replication for the affected tables.

管道错误 #

🌐 Pipeline errors

失败的管道可以自动恢复。检查日志中是否有持续的连接、权限、模式或目标错误，修复原因，并在需要时重启。Supabase 在重复失败后会停止管道；已停止的管道需要手动启动。

🌐 A Failed pipeline can recover automatically. Check logs for persistent connectivity, permission, schema, or destination errors, fix the cause, and restart if needed. Supabase stops pipelines after repeated failures; a Stopped pipeline requires a manual start.

处理复制延迟 #

🌐 Dealing with replication lag

当 Postgres 生成 WAL 的速度比 Pipelines 确认进度的速度快时，滞后就会增加。在初始同步、写入高峰和从停机恢复时，出现一些滞后是正常的。持续增长或 WAL 保留缩短需要调查。

🌐 Lag grows when Postgres produces WAL faster than Pipelines confirms progress. Some lag is expected during initial sync, write bursts, and recovery from downtime. Sustained growth or shrinking WAL retention requires investigation.

调查延迟 #

🌐 Investigate the lag

1. 打开管道，比较 等待同步 与 WAL 保留剩余量 和 槽状态。
2. 查看 连接状态 和 上次签到 以了解连接或反馈问题。
3. 检查表的状态，看是否有初始同步或表错误。
4. 打开复制日志，查看目的地错误、速率限制、重试或重复重启情况。
5. 将延迟趋势与源活动进行比较，比如批量导入、大额事务或长时间运行的写入操作。

常见原因包括目标、源或管道资源限制过慢、网络延迟，以及管道停止或断开连接。

🌐 Common causes include a slow destination, source or pipeline resource limits, network latency, and stopped or disconnected pipelines.

初始同步和表同步槽 #

🌐 Initial sync and table-sync slots

管道使用一个主要槽以及每个活跃表同步工作线程最多一个临时槽。这些槽会保留在复制行时所做的更改。复制和追赶完成后，临时槽会被移除，表会继续通过主槽处理。

🌐 Pipelines uses one main slot plus up to one temporary slot per active table-sync worker. These slots retain changes made while rows are copied. After copying and catch-up finish, the temporary slot is removed and the table continues through the main slot.

如果一个表同步槽丢失了，该表必须重新执行初始同步。自动重试可以恢复单个表；手动表重启会暂时停止整个流水线。

🌐 If a table-sync slot is lost, that table must repeat its initial sync. Automatic retries can recover individual tables; a manual table restart temporarily stops the whole pipeline.

为了提高复制吞吐量：

🌐 To improve copy throughput:

• 当一个大表成为瓶颈时，增加每个表的初始同步连接数。
• 当需要同时复制多个表时，增加 表同步工作线程。
• 减少批量写入，直到表格在线并且延迟追上为止。

更高的并发会使用更多的源连接，额外的工作线程需要更多的插槽。只有在源数据库、网络和目标有容量时才增加它。参见 设置默认值和限制。

🌐 Higher concurrency uses more source connections, and additional workers need more slots. Increase it only while the source database, network, and destination have capacity. See setting defaults and limits.

根据插槽状态来回应 #

🌐 Respond based on the slot status

要找回丢失的主插槽，打开 编辑管道 > 高级设置，并将 失效插槽行为 设置为 重新创建插槽。查看下面的效果，然后根据当前状态点击 应用并重启管道 或 应用并启动管道。

🌐 To recover a lost main slot, open Edit pipeline > Advanced settings and set Invalidated slot behavior to Recreate slot. Review the effects below, then click Apply and restart pipeline or Apply and start pipeline, depending on its current state.

这会替换所有目标表。 现有的源行仅会复制到选择用于初始同步的表；被排除的表则只会从新变更开始同步。再次处理的数据会重新计费。

或者，停止并删除管道，然后创建一个新的。删除时会自动移除该管道的主槽、表同步槽以及保存的复制状态（前提是源数据库可访问）。它会保留源表、现有目标数据以及共享的Pipelines安装。

🌐 Alternatively, stop and delete the pipeline, then create a new one. Deletion automatically removes that pipeline's main slot, table-sync slots, and saved replication state when the source database is reachable. It leaves source tables, existing destination data, and the shared Pipelines installation in place.

降低未来延迟风险 #

🌐 Reduce future lag risk

• 在创建时查看WAL 保留建议，并在启动后继续监控保留情况。
• 只发布你需要的表格和操作。
• 在源正在接收写入时，避免长时间停顿。
• 尽量在比较清闲的时候安排批量写入和初始同步。

重启表格 #

🌐 Restarting tables

重新启动表复制，以从头重建一个或多个目标表，例如在模式更改或不可恢复的表错误之后。重新启动管道 会使用已保存的复制进度重新开始过程；它不会请求重建表。有关在初次同步或丢失插槽恢复期间的例外情况，请参阅 管道重启和恢复行为。

🌐 Restart table replication to rebuild one or more destination tables from scratch, for example after a schema change or an unrecoverable table error. Restart pipeline restarts the process using saved replication progress; it does not request a table rebuild. See pipeline restart and recovery behavior for exceptions during initial sync or lost-slot recovery.

当你重新启动表复制时：

🌐 When you restart table replication:

• 受影响的目标表中的所有现有数据都会被删除。 原始的 Postgres 源表及其行保持不变。
• 对于被选中进行初始同步的表，Pipelines 会再次复制发布中包含的所有当前源行，然后继续进行正在进行的复制。未被初始同步包含的表只会同步新的更改；它们现有的源行不会被复制。
• 表格重启只会重置所选表的复制进度。
• 再次处理的数据将会再次收费。

管道会暂时停止以应用表重启。仪表板会自动重启它，或者如果它已经停止则会启动它。在此过程中，其他表的复制会暂停，它们未完成的初始同步可以从头重新开始。

🌐 The pipeline stops temporarily to apply the table restart. The Dashboard restarts it automatically, or starts it if it was stopped. Replication for other tables is paused during this process, and their unfinished initial syncs can restart from scratch.

在重启之前，使用 编辑管道 检查 初始同步 的选择。包括任何你需要重新复制其现有源行的受影响表，然后应用你的更改。从 数据库 > 管道 列表中打开管道。

🌐 Before restarting, use Edit pipeline to check the Initial sync selection. Include any affected tables whose existing source rows you need to copy again, then apply your changes. Open the pipeline from the list on Database > Pipelines.

重启一张表 #

🌐 Restart a single table

1. 点击表格行上的重启图标。
2. 查看确认对话框中的表名、数据替换和费用详情。
3. 点击 重新启动复制。

重启多个表 #

🌐 Restart multiple tables

1. 点击 重新启动所有表，或打开旁边的箭头菜单并选择 仅重新启动失败的表。
2. 查看受影响的表格、数据替换和费用明细。当请求运行时，失败的表格操作会影响每一个失败的表格。
3. 确认 重启所有表 或 重启失败的表，与你选择的范围一致。

如果表重启失败，请在重试前刷新管道和表状态。如果管道仍然是已停止，请明确地启动它。

🌐 If a table restart fails, refresh the pipeline and table states before retrying. Start the pipeline explicitly if it remains Stopped.