Postgres逻辑复制卡在LSN，如何获取pg_replication_origin_advance所需的下一个LSN？

一、获取关键LSN信息 #

先在订阅端执行以下查询，明确各节点LSN状态：

1. 查看订阅的复制原点当前卡住的LSN：

SELECT roident, roname, rolsn FROM pg_replication_origin;

返回的rolsn就是你提到的卡住的33533/7D2841D8。

2. 查看订阅端已接收的最新LSN：

SELECT subname, received_lsn FROM pg_stat_subscription;

这里的received_lsn就是你需要的下一个目标LSN——因为你提到这个值一直在推进，说明订阅端已经接收完成这部分日志，可以安全跳过到这个位置。

二、执行LSN跳过操作 #

1. 停止订阅 #

ALTER SUBSCRIPTION 你的订阅名称 DISABLE;

替换你的订阅名称为实际订阅的名称。

2. 调用pg_replication_origin_advance跳过卡住的LSN #

用第一步查到的roident（复制原点ID）和received_lsn（已接收的最新LSN）执行：

SELECT pg_replication_origin_advance(
    (SELECT roident FROM pg_replication_origin WHERE roname = '你的订阅名称'),
    '查到的received_lsn值' -- 例如'33533/80000000'
);

注意：必须确保目标LSN是订阅端已接收完成的，不能指定比received_lsn更大的值，否则会引发数据不一致。

3. 重新启用订阅 #

ALTER SUBSCRIPTION 你的订阅名称 ENABLE;

三、验证修复效果 #

1. 主节点查看复制槽大小是否回落：

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS slot_size
FROM pg_replication_slots WHERE slot_type = 'logical';

2. 订阅端查看应用进度是否恢复：

SELECT subname, received_lsn, applied_lsn FROM pg_stat_subscription;

确认applied_lsn开始追赶上received_lsn。

四、后续排查建议 #

• 通过AWS CloudWatch查看Postgres日志，搜索logical replication worker相关条目，定位卡住事务的具体错误原因。
• 核对订阅端与主节点的表结构，确保主键、唯一约束等完全一致，结构不匹配是逻辑复制卡住的常见原因。

内容的提问来源于stack exchange，提问作者mj_