昨天晚上三点，老张给我打电话，声音都变了：“数据库崩了，所有订单数据查不到，客户投诉电话快被打爆了。”类似的求助，我一年能接到几十个。PG 数据库崩溃这事，真是让人慌。但慌归慌，只要走对修复流程，九成以上的数据都能捞回来。今天我把这套流程拆开来讲，你一定要记牢。
第一步，先判断崩溃类型。PG 数据库崩溃大致分两类：一种是系统层面的，比如服务器断电、内存爆满、硬盘故障；另一种是数据库内部的，比如事务日志写坏、索引损坏、数据文件不一致。怎么判断？看错误日志。PG 的日志文件一般在 pglog 目录下，打开看看几行。如果出现 “PANIC: could not write to file” 之类的，大概率是磁盘问题；如果出现 “ERROR: invalid page in block” 之类的，则基本是数据文件损坏。别急着动手修，先弄清楚到底是哪个“敌人”，不然修错方向，反而把还能用的数据也弄坏。比如有一次，一个用户看到 “could not open file” 就以为是文件损坏，结果其实只是磁盘空间满了，清理一下就好了。所以，第一步的核心只有一个字：看。看日志、看系统状态、看硬件健康度。
第二步，根据崩溃类型选择修复工具。系统层面的崩溃（比如断电后数据库起不来），常用的是 pgresetxlog。它能重置 WAL 日志，让数据库强制启动。但使用前一定要注意：它会把未提交的事务丢掉，也就是说可能会丢失一部分数据。跑这个命令前，先把 data 目录完整备份一份。具体命令示例：（路径换成你的实际路径）。跑完后数据库一般能启动，但数据完整性不保证。如果是内部损坏，比如某个表坏了，就用 pgrepair 或 pgrecovery。这些工具能扫描数据文件，把损坏的块标记出来，然后从备份或 WAL 中恢复。没有备份只能用 pgdumpall 全库导出，但导出时可能遇到坏块，这时需要加 和 参数跳过错误。记住，工具选对了，修复效率能翻倍。我见过有人不分青红皂白直接跑 pgresetxlog，结果把好端端的 WAL 链搞断，修复时间多花了三倍。
第三步，修复完成后做数据校验。这一步很多人会跳过，觉得数据库能启动就万事大吉，但这是大忌。PG 数据库启动成功并不代表数据全对。你需要用 VACUUM 和 ANALYZE 检查表和索引。VACUUM 能清理死元组、释放空间；ANALYZE 能更新统计信息，保证查询计划正确。更严格的做法是跑 pgcheck 进行约束检查，或用 pgchecksums 验证数据文件完整性。如果发现某个表的数据有问题（比如查询返回空值或乱码），就得从备份里单表恢复。实在没有备份，只能用 pgfiledump 直接从数据文件提取原始数据，但这需要专业经验。我有个客户，修完库后没做校验，一个月后发现某字段全是 NULL，业务逻辑全乱，只能回滚到一个月前的备份。所以，第三步就是给数据做个“体检”，确保它真的能干活。
这还没完，你得知道什么时候该放弃。是的，放弃也是一种策略。如果数据库损坏太严重——比如整个 data 目录被删了，或者硬盘出现物理故障——再怎么修也是白费力气。这时最实际的做法是用备份恢复。PG 的备份策略，我建议至少用 pgbasebackup 做全量备份，再加上连续归档的 WAL 日志。这样一旦出事，就可以用 pgrestore 还原到最近的时间点。没有备份只能靠 WAL 日志了。PG 的 WAL 日志默认保存在 pgwal 目录，大小一般是 16 MB 一个。如果你有完整的 WAL 链，可以用 pgrewind 把数据库恢复到崩溃前的状态。但要注意，WAL 日志如果被覆盖，就只能接受数据丢失的现实。所以，备份是王道，别等出事才后悔。
说到工具，还得提一下 pgrecovery。它是 PG 社区的开源项目，专门用来从损坏的数据文件中提取可用数据，不依赖 WAL 日志，直接读取数据文件，把能读的块全部捞出来。用法也很简单：编译安装后，运行 。跑完后会得到一个完整的 SQL 文件，导入新库就能使用。但有个坑：它只能恢复数据，不恢复索引和约束，导入后需要重新建索引。而且如果文件头都损坏，pgrecovery 也救不了。这时只能靠 pgfiledump 逐块分析。pgfiledump 更底层，直接读二进制数据块，能提取出元组，但要求对 PG 的存储结构非常熟悉，否则提取出来的可能是乱码。因此，这类工具一般留给 DBA 用，普通用户不要轻易尝试。
整个修复流程，我最想强调的一点是：别慌。PG 数据库崩溃后，数据恢复的黄金窗口期其实挺长的。只要不乱操作，比如随便重启、乱删文件，数据大概率能救回来。我见过最夸张的案例，客户数据库崩溃三个月，硬盘都没动，我们用 pg_recovery 把 99% 的数据捞出来了。所以，冷静是第一位的。按我说的三步走：判断类型、选对工具、校验数据。每一步都稳扎稳打，别跳步。如果实在拿不准，就找专业 DBA 帮忙。PG 社区里有很多高手，去邮件列表或论坛问，一般都能得到靠谱的建议。别自己瞎试，否则数据可能越修越坏。
我得说一句：数据恢复是补救，预防才是根本。PG 数据库运维，我建议做好三件事：第一，定期全量备份，至少每天一次；第二，开启 WAL 归档，把日志存到别的磁盘或云上；第三，监控磁盘空间和内存，别让系统资源耗尽。这三件事做好了，数据库崩溃的概率能降低 90%。即使真崩了，恢复时间也能从小时级降到分钟级。所以，别等出事了才学修复流程，现在就去检查你的备份策略。记住，数据是你的命根子，别让它裸奔。
