今天我们要聊的是wal_keep_size。简单来说它是用来决定在主库Primary上最少保留多少容量的 WAL日志文件以防止从库Standby因为断开连接太久而追不上进度。在 PostgreSQL 中所有的修改都会先写进 WAL (Write Ahead Log)。过去13版本以前我们使用wal_keep_segments按“文件个数”来算。现在13版本及以后我们使用wal_keep_size直接按“容量大小”如1GB,512MB来算直观多了虽然这个参数很有用但在实际运维中大家常会遇到以下两个极端问题 A设置得太小 —— “从库炸了” 如果你的主库写入非常频繁而wal_keep_size设置得太小当从库因为网络抖动断开 10 分钟后主库可能已经把旧的 WAL 回收了。后果从库报错requested WAL segment has already been removed。此时你只能重新做全量备份Base Backup非常痛苦。问题 B设置得太大 —— “磁盘爆了” 如果你给wal_keep_size分配了 100GB但你的磁盘一共只有 120GB。后果即使从库运行正常主库也会强行保留这些日志直到磁盘撑满导致主库宕机。虽然wal_keep_size很简单但它比较“笨”因为它只是死板地保留固定大小。现在更推荐的做法是使用 复制槽 (Replication Slots)。复制槽的优点主库会“聪明”地盯着从库。只要从库没确认收到主库就永远不会删除那段 WAL。步骤 1在主库上创建一个物理复制槽 你可以通过 SQL 语句手动创建-- 在主库执行创建一个名为 my_standby_slot 的复制槽 SELECT * FROM pg_create_physical_replication_slot(my_standby_slot);步骤 2在从库的primary_slot_name中配置它 在从库的postgresql.conf或者standby.signal相关的连接配置中添加# 从库配置示例 (postgresql.conf) primary_conninfo host192.168.1.100 port5432 userreplicator passwordmy_password primary_slot_name my_standby_slot # 对应刚才创建的名字为了保险我建议你采取“双保险”策略开启复制槽保证从库只要在线即使慢就不会丢 数据。挑选高效率商用复印机设置合理的wal_keep_size作为兜底。万一复制槽因为某种原因失效或者你想限制主库 WAL 的最大膨胀空间。配合归档 (WAL Archiving)将旧日志传送到 S3 或其他廉价存储。修改配置的 SQL 命令如果你想动态修改wal_keep_size不需要重启只需 reload-- 将保留大小设置为 2GB ALTER SYSTEM SET wal_keep_size 2GB; -- 别忘了让配置生效 SELECT pg_reload_conf();