API缩容至0实例后WAL复制槽bytes_behind非0相关问题咨询

问题分析 #

你提到API已缩容至0实例、无新INSERT操作，但查询复制槽时bytes_behind仍为440。这个非0值不一定表示复制槽未完全同步。从你的查询结果来看：

user=> SELECT slot_name,
       pg_wal_lsn_diff(
          pg_current_wal_lsn(),
          restart_lsn
       ) AS bytes_behind,
       active,
       wal_status
FROM pg_replication_slots
WHERE wal_status <> 'lost'
ORDER BY restart_lsn;
            slot_name             | bytes_behind | active | wal_status 
----------------------------------+--------------+--------+------------
app_publisher_connector |          440 | t      | reserved
(1 row)

这里的active为t说明复制槽仍有活跃连接，wal_status为reserved表示该槽保留了部分WAL日志。这440字节很可能是复制槽已消费但尚未清理的残留日志，或是连接断开前最后一批未完全确认的WAL片段——由于没有新写入，这个数值不会再增长。

判断复制槽完全同步的方法 #

• 检查bytes_behind是否稳定为0：在无新写入的情况下，等待一段时间后再次查询，若bytes_behind变为0且不再变化，说明复制槽已同步完成。
• 对比restart_lsn与当前WAL位置：执行SELECT restart_lsn, pg_current_wal_lsn() FROM pg_replication_slots WHERE slot_name = 'app_publisher_connector';，当两者值完全相等时，bytes_behind必然为0，代表复制槽的已处理位置追上了数据库当前的WAL写入位置。
• 观察wal_status状态：当复制槽完全同步且无新写入时，wal_status可能从reserved变为unreserved（前提是复制槽的消费者已停止请求WAL日志）。不过如果复制槽仍保持活跃连接，wal_status可能维持reserved，但只要restart_lsn追上当前LSN，就说明同步完成。
• 确认复制槽的消费者状态：如果app_publisher_connector这个消费者已经停止运行，可观察复制槽是否从active变为inactive。一旦变为inactive且restart_lsn等于当前LSN，即可确认同步完成。

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