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。 |

相关推荐
小马同学-26 分钟前
mysql数据库原理
数据库·mysql
东方护航数据恢复(深圳)37 分钟前
政务信创案例:达梦 DM8 数据库掉电页损坏,48 小时修复实录【东方护航数据恢复深圳店】
数据库·数据恢复·it运维·服务器数据恢复·二次开盘·硬盘开盘
AC赳赳老秦2 小时前
OpenClaw 数据引用规范自动生成:为公开数据构建可信来源标注与标准引用体系
大数据·开发语言·汇编·数据库·人工智能·deepseek·openclaw
小蒜学长2 小时前
校园社团招新网站的设计与实现(代码+数据库+LW)
java·数据库·spring boot·后端·校园社团招新网站
布莱克6053 小时前
MySQL 增删改查(CRUD)语法详解
数据库·mysql·增删改查
Dovis(誓平步青云)3 小时前
几个方案来回选不定?做一个随时切换的候选推荐页
android·java·服务器·开发语言·javascript·数据库·智能化
2501_933670794 小时前
2027届大数据管理与应用求职数字化转型顾问:项目、SQL、业务理解怎么排优先级
数据库·sql
东方护航数据恢复(深圳)5 小时前
物流案例:勒索病毒 Mallox 加密 ERP 数据库,旧备份 + 残留页重组实录【东方护航数据恢复深圳店】
数据库·数据恢复·勒索病毒·二次开盘·开盘·数据镜像
.Hypocritical.5 小时前
Redis从入门到实战:核心原理、场景落地与避坑指南
数据库·redis·缓存
梦想画家5 小时前
SQLMesh Python 模型入门(二):依赖管理、引擎实战与内存优化
数据库·python·sqlmesh