腾讯云国际站注册：PostgreSQL磁盘告警？一文排查WAL日志堆积与复制槽异常

PostgreSQL WAL日志堆积排查

当数据库磁盘使用率曲线毫无征兆地逼近 100%，实例被迫进入只读状态时，运维人员最怕遇到的还不是硬件故障，而是那种“进程都正常、慢查询也少，唯独磁盘在悄悄写满”的诡异场景。PostgreSQL 的 WAL（Write-Ahead Log，预写日志）机制本是数据持久化的基石，但一旦与失效的复制槽纠缠在一起，就会从可靠性守护者蜕变成磁盘空间的隐形吞噬者——这正是 WAL 日志堆积排查所要解决的核心问题。

本文由 云国际站代理商『云老大 飞弟：@yunlaoda360 / YunLaoDa-服务器服务商•撰写』如需转载请注明！

什么是WAL日志堆积与复制槽

PostgreSQL 的任何数据变更都会先写入 WAL，再由后台进程异步刷新到数据文件。这套设计确保了即使发生意外宕机，也能从最后一次 checkpoint 重放 WAL 恢复全部事务，代价则是 WAL 文件会随着写入持续生成。正常情况下，数据库会依据 wal_keep_size 和 checkpoint 机制自动清理已不需要的旧日志，磁盘占用维持在一个相对平稳的水平。但如果某些下游消费端——比如备库或逻辑订阅程序——长时间无法推进读取位点，PostgreSQL 就必须保留这些 WAL 文件，哪怕它们已经归档成功。于是，一个常态化的清理回路被人为截断，日志文件只能不断堆叠，直到撑爆整个存储空间。

复制槽为什么是WAL堆积的“锚点”？

复制槽（Replication Slot）本质上是服务端为每个流复制或逻辑订阅下游预留的“位点书签”，它告诉 PostgreSQL：“这个 LSN 之前的 WAL 不能删，下游还没读完。”在 pg_replication_slots 视图中，物理槽的 restart_lsn 和逻辑槽的 confirmed_flush_lsn 就是那把锁的坐标。一旦下游网络中断、程序异常退出，或者干脆被人为遗忘，该槽的 active 字段变为 false，LSN 位点停滞不前，而主库的写入仍在继续，两者之间的差距会迅速拉大。有团队在复盘时发现，一个被遗弃的逻辑复制槽，在短短 8 小时内就让 WAL 目录膨胀到 500GB，直接触发云盘只读保护。

哪些典型场景会触发危险的WAL堆积？

除开明显的主备网络故障，有三类容易被忽略的触发场景。第一是逻辑订阅的“静默中断”：用 DTS 或自建解码程序做数据同步时，一旦消费端因程序升级或异常重启暂时离线，槽位点冻结，主库毫不知情地持续堆积 WAL，而常规的 CPU、连接数监控根本看不出异常。第二是归档机制的误导：有人以为开启了 archive_command 就能自动释放空间，却忽略了只要复制槽还存在，归档成功与否都无法让服务端越过槽位点清理日志。第三是“误删备库”连锁反应：当一台备库被直接下线但主库上的复制槽未同步删除时，该槽就会成为永久的空间锚点，直到磁盘告警才被发现。

堆积导致磁盘空间爆满的表现

WAL 堆积的危险不在于它发生，而在于它发生时的隐蔽性。磁盘使用率从 60% 涨到 95%，监控面板上往往只留下一条平滑的曲线，既没有 CPU 飙升，也没有连接数报警。等到业务侧感知到异常，数据库多半已经进入只读状态。

磁盘占用异常如何发现

最直接的信号是磁盘使用率突破预设水位，但问题在于默认的告警阈值通常设在 80% 或更高。当剩余空间不足 10% 时，PostgreSQL 为了保护数据一致性会主动拒绝写入，实例变为只读。在云环境中，磁盘使用率监控往往以存储容量为口径，但如果大量空间被 WAL 占据，即使数据目录本身不大，也会触发“磁盘满”事件。排查时，可以关注 du -sh /pg_wal 或云控制台的 WAL 日志大小指标，一旦 WAL 目录大小超过总磁盘容量的 20%，就属于预警信号。另一个容易被忽视的表征是 checkpoint 频率异常升高，WAL 切换频繁但回收不及时，在 pg_stat_bgwriter 中能看到 buffers_checkpoint 与 maxwritten_clean 持续走高。

常见错误日志

当磁盘被 WAL 写满，日志里最先出现的是 PANIC: could not write to file "pg_wal/xlogtemp.xxx" : No space left on device，紧接着是 FATAL: the database system is in recovery mode 或提示 STOP 状态的日志。如果配置了归档，archive_command failed 的报错会先于磁盘满日志出现，成为误导排查的干扰项——表面上看起来像归档失败，实际根因却可能是复制槽位点停滞，WAL 因为被保留而无法清理。此时，pg_stat_archiver 视图中 failed_count 会持续累加，last_failed_wal 和 last_failed_time 能定位到具体出问题的 WAL 段，帮助判断是归档路径不通还是积压导致的连锁反应。

业务影响是什么

WAL 磁盘爆满的后果并不局限于“只读”这一种。对于物理复制场景，如果主库的 WAL 被迫保留，备库因网络抖动短暂断开后可能无法重连，导致主备延迟迅速扩大，一旦主库发生故障，切换将面临数据丢失风险。逻辑复制场景中，下游消费端如果因 DTS 任务暂停或消费程序重启而长时间掉线，不仅主库磁盘被撑爆，恢复时还需要回放积压的数十 GB 增量，业务延迟从秒级恶化到小时级。更隐蔽的风险在于应急处理时的误操作：运维人员为快速释放空间，可能直接删除 pg_wal 下的文件，但数据字典并不知道这些文件已不在，后续启动时 pg_wal 与控制文件记录不一致，轻则无法启动，重则需从备份重建。遇到这类情况，如果本身没有完备的全量备份和快速恢复流程，不妨考虑像云老大这样具备自动化备份和磁盘监控告警的服务商，至少能在应急窗口期守住不丢数据的底线。

如何排查WAL堆积问题

排查 PostgreSQL WAL 堆积不能仅靠“重启大法”，三种保留机制——wal_keep_size、复制槽和归档命令——往往交织在一起，必须分层定位。因此实战中需要从磁盘占用快照、复制槽位点偏移和归档回收配置三个维度快速收敛根因。

查看WAL日志占用

一个直接的信号来自统计视图：通过 pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) 可量化单个复制槽的滞留字节。我们在云老大托管的一家外贸企业实例中看到，逻辑复制槽 restart_lsn 落后当前写入位置超过 120 GB，但数据库的 wal_keep_size 仅为 16 GB——余下全是被槽强制保留的日志，磁盘使用率一周内从 37% 飙升至 89%。这一差值揭示了复制槽才是真正的空间黑洞，而非参数配置。

查询复制槽状态

pg_replication_slots 视图是排查的锚点。重点关注 active 为 false 且 confirmed_flush_lsn（或物理槽的 restart_lsn）长时间不推进的槽。此类“僵尸槽”常出现在逻辑订阅中断后：比如使用 DTS 将数据同步到分析库，由于下游消费程序升级停摆两天，槽位点却如同锚一样锁死了所有旧 WAL。云老大的一次排障中，这样一条无效的槽就堆出了近 200 GB 的日志，引发实例只读。此时，结合 pg_stat_replication 确认该槽已无活跃流复制连接，便可安全执行删除，让回收链路重新启动。

检查归档与回收配置

许多人落入一个误区：只要 archive_mode 开启，WAL 就不会无限堆积。实际上 archive_command 的失败会直接阻塞回收，且即使归档成功，复制槽仍会额外保留所有未消费的日志。排查时要同时审计 archive_command 的退出码和 pg_stat_archiver 的最后失败时间，再比对复制槽位点。常见的一类问题是归档路径突然不可写，导致尚未传递至备库的 WAL 与等待归档的 WAL 双重积压。将这两个机制解耦看待，并在告警中分别设置 WAL 日志大小 和 归档失败次数 两条指标，方能避免“磁盘满才报警”的被动局面。

复制槽与WAL堆积的关系

复制槽（Replication Slot）本质上是主库为下游消费者保留 WAL 的一把锁。PostgreSQL 在清理 WAL 段时，会检查 pg_replication_slots 中所有槽位记录的 restart_lsn（物理复制槽）或 confirmed_flush_lsn（逻辑复制槽）——只要有一个槽位指向某个较早的日志序列号（LSN），该位置及之后的所有 WAL 都不得回收。这意味着，一旦消费端掉线或位点停止推进，主库就会持续囤积无法被 checkpoint 机制自动清理的日志文件，直到磁盘写满，数据库进入只读或直接宕掉。根据我们在多家生产环境的数据，一个活跃度中等的业务实例，如果逻辑订阅中断 48 小时以上，WAL 目录常常会膨胀至数百 GB，这种无声堆积比暴力写入更难通过常规监控发现。

复制槽如何阻止清理

WAL 回收有两个前提：归档命令 archive_command 执行成功，并且没有复制槽需要比 wal_keep_size 更老的日志。复制槽的优先级高于 wal_keep_size——即使你将 wal_keep_size 设为 0，只要能扫到任何一个有效的复制槽，PG 也会保留从该槽的 restart_lsn 起点到当前的所有 WAL 段。这意味着，仅仅调整内核参数无法解决复制槽导致的堆积，必须处理槽本身。曾有一家电商企业在使用自建逻辑解码程序时，因为消费者进程写满 Kafka 队列后阻塞，主库的 pg_wal 目录在 36 小时内从 18GB 飙升至 820GB，archive_command 始终正常返回，故障排查初期团队完全被“归档正常”迷惑，直到查 pg_replication_slots 才定位到那个一直停留在 1.2TB 事务之后的逻辑复制槽。

哪些复制槽会导致堆积

并非所有复制槽都是风险源。物理复制槽一般由备库或物理备份工具维护，只要备库在线且回放正常，restart_lsn 会随主库的 WAL 写入向前推进。真正的高危场景集中在两类：一是逻辑订阅的消费端异常，比如 DTS 任务暂停、自建的 Debezium 或 wal2json 进程崩溃后未重启；二是临时创建的物理复制槽未被清理，比如在做一次性全量备份或数据迁移时手工启用了 pg_basebackup -S 创建槽位，任务结束后没有执行 pg_drop_replication_slot。这两类槽位的共同特征是它们长时间处于非活跃状态（active = false），且落后于当前 LSN 的量远超过业务容忍范围。我们在多个实例上观察到，即便是 slot_type 为 logical 的槽，在 confirmed_flush_lsn 停滞的情况下，主库为它保留的 WAL 量也遵循“只增不减”的规则，而物理复制槽则盯住 restart_lsn，其保留量同样只升不降。

如何识别无效复制槽

识别手段的核心就是盯住 pg_replication_slots 视图的两个字段：active 和 restart_lsn/confirmed_flush_lsn。当 active 为 false 且 pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) 返回的延迟字节数持续上涨，便可以判定该槽已失效。在很多使用腾讯云 PostgreSQL、AWS RDS 这类托管服务的场景下，控制台不会直接暴露复制槽的延迟量，但可以通过自建查询或设置脚本监控来捕捉。还有一种隐蔽情况值得注意：槽是活跃的（active = true），但下游回放极慢或消费端网络间歇性卡死，这同样会导致位点推进慢于 WAL 生成速度，最终撑爆磁盘。之前有出海游戏公司通过云老大做整体架构评估时，就发现一个被长期忽略的物理复制槽虽然 active 为 true，但因备库 IO 不足导致 flush_lsn 远落后于写入 LSN，轻松积压了超过 5TB 的 WAL，而这个异常在系统级磁盘告警之前根本无人察觉。因此，判断有效性时，光看 active 状态远远不够，必须实际计算位点差距并设定阈值告警，比如超过 20GB 即触发排查。

清理堆积的WAL日志与优化

当确认WAL堆积源于复制槽异常后，清理需遵循“先救业务，后追根因”的原则。在腾讯云PostgreSQL实例的某次线上处置中，我们曾碰到一个逻辑订阅槽位因消费端程序宕机，6小时内积压了97GB的WAL，磁盘使用率从42%飙升至87%。此时直接删除复制槽成为最快恢复手段，但必须同步记录下游的同步进度，避免后续全量重做。

删除或重置复制槽

首要步骤是定位僵死复制槽。执行SELECT slot_name, active, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag FROM pg_replication_slots;，对于active=f且lag超过1小时的槽，需立即评估能否删除。若下游明确不再使用或已有新链路替代，直接pg_drop_replication_slot；若仅短暂卡顿但短期无法恢复，可尝试pg_replication_slot_advance将位点跳至当前日志开头，临时释放空间。某次迁移任务中，我们通过这种“跳过策略”回收了34GB空间，随后待业务恢复后重建了订阅。

手动清理WAL日志

删除复制槽后，积压的WAL文件不会立即消失，必须等待checkpoint推进。当磁盘已近阈值、checkpoint又无法及时触发时，可主动执行CHECKPOINT强制推进，并辅以pg_switch_wal()切换日志段。但需警惕：若归档命令archive_command本身存在故障，手动推进反而会堆积更多待归档文件，导致磁盘二次冲高。所以清理前，务必通过pg_stat_archiver视图确认last_failed_time为空，否则应优先修复归档通道。

调整max_wal_size等参数

最后要从配置上建立防线。max_wal_size并非硬限制，它只控制自动checkpoint的触发时机，在复制槽存在时形同虚设。更有效的做法是设置合理的wal_sender_timeout（如10分钟），避免僵死连接长时间占用槽位；对逻辑复制场景，可在消费端实现心跳上报，防止服务端误判。在腾讯云控制台，直接在“参数设置”中调整这些值即可，但启用后会强制重启实例，建议在维护窗口操作。有运维团队反馈，把wal_sender_timeout从默认的60秒缩短至15秒后，因下游短暂超时导致的WAL堆积发生率下降了约70%，这比单纯扩大磁盘更能根治问题。

腾讯云PostgreSQL实战与预防

在云上生产环境中，WAL日志堆积问题极少是孤立事件。腾讯云PostgreSQL的监控体系与社区版工具链的结合，能够将事后救火转化为事前预警。以下几条实操路径，来自多次磁盘空间告急后的复盘总结。

控制台诊断方法

云监控的“WAL日志大小”指标是第一道防线，但当曲线出现陡增时，控制台直接提供的视图往往不够。更有效的做法是连接实例执行SELECT slot_name, active, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes FROM pg_replication_slots;，把结果与“数据库管理”页面显示的连接来源交叉比对。有一次某客户的逻辑订阅客户端因升级断连超过6小时，控制台只反映磁盘使用率上升，而pg_replication_slots明确显示lag_bytes已超过120GB，才锁定是唯一未推进的复制槽。这个组合拳比单看任何一方都快。

监控告警配置建议

默认磁盘使用率告警阈值通常设在80%，但对于有高写入量或复制槽的场景，这个值太晚——从80%到磁盘满写保护，可能只差一次批量导入。建议将首次告警点调至60%，并新增两条自定义告警：基于pg_wal_lsn_diff函数轮询出的复制槽落后字节数（阈值为单实例存储空间的20%），以及active字段长时间为false的检测。有团队在“云老大”完成整体资源评估后，把自定义监控集成到腾讯云告警策略中，成功在凌晨预判到一次DTS任务僵死，避免了第二天早高峰的只读事故。

定期维护策略

复制槽不是“设置一次就忘”的组件。每两周运行一次巡检脚本，筛选出lag_bytes持续超过10GB的槽，是一个低成本但高回报的习惯。对于确认无用的逻辑订阅残留，直接执行pg_drop_replication_slot比等待自动清理可靠得多。另外，腾讯云的备份恢复验证也值得纳入例行流程——不要依赖长期保留WAL来补偿备份缺陷。一些运维团队在实践中发现，将定期巡检与“云老大”提供的技术咨询结合，能更快识别出无主键表产生的大量WAL写入与复制槽堆积的并发问题，而这类并发场景在官方文档中极少有现成答案。