PostgreSQL logical replication 订阅端延迟高会直接影响数据同步的时效性，严重时可能导致业务数据不一致。排查这类问题需要从复制链路、订阅端状态、资源配置等多个维度逐步验证，以下是完整的排查步骤。
第一步：确认复制链路基础状态
首先需要在发布端和订阅端分别检查逻辑复制的基础配置和运行状态，确认链路本身是否存在异常。
发布端检查
在发布端查询pg_publication和pg_replication_slots表，确认发布配置正常且复制槽状态健康：
-- 查询发布配置 SELECT pubname, puballtables, pubtables FROM pg_publication; -- 查询复制槽状态，确认active为true，无异常重启记录 SELECT slot_name, plugin, slot_type, active, restart_lsn FROM pg_replication_slots WHERE slot_type = 'logical';
订阅端检查
在订阅端查询pg_subscription和pg_stat_subscription视图，确认订阅状态正常：
-- 查询订阅配置 SELECT subname, subenabled, subconninfo FROM pg_subscription; -- 查询订阅运行状态，关注latest_end_lsn和received_lsn的差距 SELECT subname, received_lsn, latest_end_lsn, last_msg_send_time, last_msg_receipt_time FROM pg_stat_subscription;
如果pg_stat_subscription中received_lsn长时间不更新，说明订阅端没有正常接收发布端的变更日志，需要先排查网络连接和订阅配置是否正确。
第二步：检查订阅端写入性能
订阅端需要将接收到的变更日志回放到本地数据库，如果写入性能不足会直接导致延迟升高。
检查慢查询和锁等待
订阅端的逻辑复制 worker 进程会执行变更回放 SQL，如果存在长事务、锁等待或者慢查询，会阻塞回放流程。可以查询pg_stat_activity视图排查：
-- 查询正在运行的复制相关进程，关注wait_event_type和wait_event SELECT pid, usename, application_name, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE application_name LIKE '%subscriber%';
如果wait_event_type为Lock，说明存在锁等待，需要排查是否有其他业务长事务持有相关表的锁资源。如果query字段中的回放语句执行时间过长，需要优化对应表的索引或者SQL逻辑。
检查磁盘 IO 性能
订阅端的 WAL 回放和数据写入都需要磁盘 IO 支持，IO 瓶颈会直接导致延迟。可以通过系统工具查看磁盘使用率，同时检查 PostgreSQL 的 WAL 相关参数配置：
-- 查询WAL相关参数
SELECT name, setting FROM pg_settings WHERE name IN ('wal_buffers', 'checkpoint_timeout', 'max_wal_size', 'min_wal_size');
如果磁盘 IO 使用率长期接近 100%，可以考虑升级磁盘类型，或者调整checkpoint_timeout和max_wal_size参数减少检查点频率，降低 IO 压力。
第三步：检查网络传输状态
发布端到订阅端的网络延迟和带宽不足也会导致订阅端接收变更日志的速度变慢。
可以在订阅端服务器上通过ping命令测试到发布端的网络延迟，通过iperf工具测试网络带宽。如果网络延迟超过 100ms 或者带宽利用率长期超过 80%，需要联系网络运维排查链路问题。
同时可以检查订阅端的max_logical_replication_workers和max_sync_workers_per_subscription参数，默认配置可能无法充分利用网络带宽：
-- 查询逻辑复制相关 worker 参数
SELECT name, setting FROM pg_settings WHERE name IN ('max_logical_replication_workers', 'max_sync_workers_per_subscription');
如果订阅端需要同步的表数量较多，可以适当调大这两个参数，提升并行同步的能力。
第四步：检查订阅端参数配置
部分 PostgreSQL 参数配置不合理也会间接导致逻辑复制延迟升高。
| 参数名称 | 作用 | 优化建议 |
|---|---|---|
| shared_buffers | 控制共享内存缓冲区大小 | 建议设置为服务器内存的 25% 左右，提升数据读写效率 |
| work_mem | 控制排序和哈希操作的内存大小 | 如果回放过程中有大量排序操作，可以适当调大该参数 |
| maintenance_work_mem | 控制维护操作的内存大小 | 同步过程中如果有索引创建等维护操作，调大该参数可以提升速度 |
| synchronous_commit | 控制事务提交的同步级别 | 订阅端可以设置为 off，降低提交等待时间，提升回放速度 |
调整参数后需要重启 PostgreSQL 服务生效，重启后需要再次观察订阅延迟是否有下降。
第五步：验证延迟是否恢复正常
完成上述排查和优化后，再次查询订阅端的pg_stat_subscription视图，观察received_lsn和latest_end_lsn的差距是否缩小，同时可以通过对比发布端和订阅端的表数据量、最新更新时间确认延迟是否已经恢复正常。
如果经过上述步骤排查后延迟仍然没有下降，可以开启 PostgreSQL 的逻辑复制调试日志，收集更详细的运行信息后提交官方社区或者专业运维人员进一步分析。
PostgreSQLlogical_replication订阅端延迟排查步骤修改时间：2026-07-02 00:12:34