PostgreSQL 数据库恢复：症状、原因、方法与难点

PostgreSQL 是这两年国内增速最快的开源关系库，政企、互联网、GIS 系统全面开花。它的数据文件结构在所有开源库里最透明，但透明不等于好修——WAL 链一断，一样要动用底层手艺。

PostgreSQL 损坏的常见症状

查询级：经典报错 "could not read block X in file"和"invalid page header"——页头校验不过的页级损坏；索引扫描报 xMIN/xMAX 异常、amcheck 输出一堆 heap tuple index inconsistency。启动级：报 could not locate a valid checkpoint record（控制文件损坏）、WAL 文件缺失或 invalid record length、数据库无法启动。备份级：pg_basebackup 中途失败、pg_dump 报快照读到了坏页。系统级：fsync 写不进、relation 文件丢失（对应表整个不见）。复制级：从库 replay 卡住报 WAL 不一致，主从分叉。

PostgreSQL 损坏的常见原因

断电与硬杀：PG 的崩溃恢复依赖 WAL replay，理论上很稳——但底层存储不保证写原子性（廉价 RAID 卡缓存、云盘抖动）时照样产生半写页。磁盘与文件系统故障：坏块直接打在数据文件上。磁盘写满：WAL 洪峰把盘撑爆，写入全停。fsync=off 的"性能配置"：有人为了跑分关掉持久化，一次断电就是一场灾难。人为：rm -rf 数据目录、误删表空间符号链接、误用 pg_resetwal、不停机直接拷文件当备份。OOM：内存不够把 bgwriter/checkpointer 打死，留下烂尾页。

PostgreSQL 的恢复方法

崩溃自愈：正常启动自动 replay WAL，轻度不一致自己修好。PITR 时间点恢复：从基础备份+归档 WAL 恢复到指定时间点（restore_command 拉日志）——PG 恢复的主流程，前提是归档链完整。页级微修：单个坏页用 zero_damaged_pages 把页清零跳过（那一页数据没了但库能跑），或用 pg_filedump 十六进制级解析 relation 文件、把幸存行抽出来重建表。索引重建：索引不一致而堆表完好的，REINDEX 即修复——索引从来不是事实来源。pg_resetwal 重置：控制文件/WAL 彻底损坏的最后手段，强推新时间线让库启动——和 SQL Server 的重建日志同性质，丢的是 WAL 里的未落盘事务。从副本取数：主库物理损坏、从库还健康的，直接从从库导出或提升切换。

PostgreSQL 恢复的难点

WAL 链完整性：PITR 差一个 WAL 段就停，归档散落在多个目录、对象存储、备份软件里，凑链是硬功夫；timeline 分叉后还要选对分支。页结构手工解析：pg_filedump 是十六进制手术，tuple 头、空位图、TOAST 溢出页都要看懂才能抽行——工具开源但经验稀缺。损坏范围界定：堆表坏还是索引坏决定截然不同的路线，amcheck 与页校验的配合诊断要精细。checksum 依赖：建库时没开数据校验和的实例，坏页发现得晚、坏得深。大对象与 TOAST：大字段拆页存储，抽页时漏了 TOAST 链字段就拼不回来。

补天时代在 PostgreSQL 恢复上的优势

团队从 PG 9.x 一路做到 16，堆表/索引/WAL/TOAST 的页结构有完整的内部解析笔记和抽行工具；PITR 链拼凑、时间线切换、页级抢救都是常规项目；对开了 checksums 的实例能给出精确的坏页清单和逐页评估——修哪页、丢哪行、成功率多少，报告里写清楚，不成功分文不收。