PostgreSQL 16.3中复制槽的配置

前言

复制槽（Replication Slot）是数据库（如 PostgreSQL）中用于保障主从复制数据一致性与安全性的核心机制，它通过在主库上为每个从库建立一个持久的状态记录点，强制主库保留该从库尚未确认接收的 WAL（预写日志），从而防止因日志过早被清理而导致从库断连后无法继续同步；简单来说，它就像一根“安全绳”，确保即使从库长时间离线或网络中断，重新连接后也能无缝续传缺失的数据，避免主从数据出现不可修复的断层。

流复制的配置不在做过多的缀述，直接基于之前搭建的流式复制配置复制槽，

配置

首先在主库上创建物理复制槽

#创建
select pg_create_physical_replication_slot('demo_slot', true);
#查询
select * from pg_replication_slots;

然后再去备库配置连接信息，由于使用的是 PostgreSQL 16.3 的搭建的流式复制，故直接在postgresql.auto.conf中配置

#在postgresql.auto.conf中添加
primary_slot_name = 'demo_slot'

最后重启备库后，在主库查看slot的状态，active=true的话说明slot已经被激活

字段名	含义与解释
slot_name	槽的名称。这是你创建槽时指定的唯一标识符，例如你的 demo_slot在配置主从连接 (primary_slot_name) 时会用到它。
plugin	插件名称。 • 如果是 物理复制 (Physical)，此值为 <null> • 如果是 逻辑复制 (Logical)，这里会显示使用的输出插件名，如 pgoutput, test_decoding等。
slot_type	槽的类型。 • physical: 用于流复制备库（Standby）。 • logical: 用于逻辑解码或逻辑订阅（Logical Subscription）。
datoid	数据库 OID。仅对逻辑复制槽有效，表示该槽关联的数据库 ID。物理复制槽与此无关，所以是 <null>。
database	数据库名称。同上，仅对逻辑复制槽有效，显示关联的数据库名。
temporary	是否为临时槽。 • True: 临时槽，当创建它的会话结束时自动删除。 • False: 持久化槽，重启后依然存在（你的 demo_slot就是这种）。
active	是否活跃。 • True: 表示有一个备库或客户端正连接并使用这个槽（你的情况）。 • False: 槽存在但没人用。如果长期为 False，说明备库断连了，需要检查网络或配置。
active_pid	活跃进程的 PID。显示主库上哪个后端进程（Walsender）正在服务这个槽。你的 79803就是那个进程的 ID。可以用 SELECT * FROM pg_stat_activity WHERE pid = 79803;查看该进程详情。
xmin	事务 ID 下限。仅对逻辑复制槽有意义。表示为了防止逻辑解码所需的事务快照被清理，系统必须保留的最早事务 ID。物理复制槽通常为 <null>。
catalog_xmin	目录事务 ID 下限。仅对逻辑复制槽有意义。类似 xmin，但是针对系统目录表的变更。
restart_lsn	重启 LSN (Log Sequence Number) ⭐这是物理复制最重要的字段。它表示：“从这个位置开始的 WAL 日志，我都还没确认备库收到了，所以主库绝对不能删除这些日志”。随着备库不断确认接收，这个值会向后推进。
confirmed_flush_lsn	已确认刷新的 LSN。仅对逻辑复制有效。表示逻辑订阅者已经成功处理并重放到的位置。物理复制槽此值为 <null>。
wal_status	WAL 日志状态。 • reserved: 正常状态，表示槽正在保留 WAL 日志。 • lost: 警告状态！表示槽需要的 WAL 日志已经被主库清理掉了，复制将中断，需要重新做基础备份。
safe_wal_size	安全的 WAL 大小。估算值，表示在当前状态下，主库还能安全地生成多少 WAL 日志而不会触发 wal_status = 'lost'。如果这个值变成负数，说明已经很危险了。
two_phase	是否支持两阶段提交。仅对逻辑复制槽有效。如果为 True，表示该槽可以复制两阶段提交（PREPARE TRANSACTION）的事务。
conflicting	是否存在冲突。仅对逻辑复制槽有效。如果在解码过程中遇到无法解决的冲突（比如表结构不一致），这里会标记为 True。