PostgreSQL中删除pg_wal的影响及备份恢复相关疑问

直接删pg_wal会不会损坏数据库，核心取决于操作时数据库的运行状态：

• 如果删除时数据库处于异常崩溃状态（比如本次WAL占满导致的服务挂死，就属于非正常关库场景），100%存在损坏风险。pg_wal存储的是还没来得及刷写到数据文件的事务记录，数据库重启时必须靠这些日志完成崩溃恢复，把所有数据页拉到一致状态。删掉这些日志后，轻则数据库直接启动失败，重则启动后存在事务丢失、数据页不一致、索引损坏、系统表错乱的问题，后续运行业务时随时可能出现无规律的报错。
• 只有一种极端情况删除后不会立刻触发故障：数据库是通过pg_ctl stop -m fast/smart模式正常干净关闭的，关库时内存里的所有脏页都已经刷写到磁盘，不需要执行崩溃恢复，这时候pg_wal里的日志都是已经应用完成的，删除后库可以正常启动，但依然会打断之前配置的WAL归档、连续PITR备份链路。

结论非常明确：只要删完pg_wal之后数据库能正常启动运行，新做的全量pg_basebackup本身是可以正常拉起恢复的，它不依赖你已经删掉的那些旧WAL条目。
pg_basebackup做全量物理备份的逻辑，是直接拷贝当前运行实例的数据目录文件，同时只拉取备份执行过程中产生的、用来保证这份备份自身一致性需要的WAL段，根本不会读取备份开始时间点之前已经被删除的旧WAL。
但这里有个极易踩的坑：能正常完成备份、能正常启动恢复，不代表备份里的数据是可靠的。如果你删pg_wal的时候数据库是崩溃状态，就算强行把库拉起来了，库里本身已经存在数据不一致、损坏的问题，这些问题会原封不动被pg_basebackup拷进备份里，后续恢复出来的库依然是带故障的，随时可能出问题。

两种操作的本质差异，是有没有过滤掉删WAL带来的底层物理损坏：

• 一致性等级不同：pg_dump是逻辑备份，它会通过数据库的一致性读快照，拿到一份逻辑上完全自洽、没有事务错乱的数据集。把这份dump导入到全新初始化的PostgreSQL实例后，得到的是一个没有底层数据页损坏、状态完全干净的库，这时候再做pg_basebackup，备份出来的内容是完全可靠的。
• 损坏传递逻辑不同：直接在删过pg_wal的原库上做pg_basebackup，原库如果存在系统表损坏、事务丢失、索引断裂、数据页checksum不匹配的问题，会完整保留在备份里，后续用这个备份恢复的库随时可能报错；而走pg_dump重新导入的流程，相当于做了一次逻辑层的清洗，所有底层物理损坏都会被过滤掉，不会带到新实例中。
• 备份链路状态不同：删完pg_wal之后，原库之前的WAL归档、时间点恢复链路会完全失效，在原库上直接做新的pg_basebackup，只是重新打了一个全量备份基线，这个基线之后的WAL归档可以正常使用，但基线之前的归档全部作废；而pg_dump导入后的实例本身就是全新初始化的，从0开始构建备份链路，不存在旧链路残留的无效WAL问题。

实操提醒：如果数据库是崩溃后直接删pg_wal强行拉起来的，不要抱侥幸心理直接使用原库或者原库生成的物理备份。优先用删WAL之前的有效备份做恢复，或者立刻做一次全库pg_dump逻辑导出，导入到全新初始化的实例后再投入生产，避免后续出现随机的数据损坏问题。

内容的提问来源于stack exchange，提问作者Nicole Staline