最近一个朋友跟我吐槽，他们公司做PG数据库还原，进度条卡在99%一动不动，等了两个小时还是纹丝不动。他急得满头大汗，因为业务系统等着上线，老板在群里催了三次。我说别慌，这事我见多了，99%卡住不是什么新鲜事，但确实挺折磨人。很多DBA一遇到这种情况就慌了，要么重启进程，要么重新跑一遍还原，结果浪费大把时间。今天我把这五个排查步骤掰开揉碎讲给你听，下次遇到直接照着来，省得走弯路。
第一步：先看日志，别光盯着进度条发呆。很多人一看到99%就以为快完了，其实还原进程可能早就卡在某个环节。PG的日志文件通常在pglog目录下，用 实时盯着，看看有没有报错信息。我见过最典型的场景是，还原进程在等待一个锁，但锁被某个会话占着不放，日志里会显示 “waiting for lock” 之类的提示。这时候光等没用，得手动查询 视图，看看哪个进程在搞鬼。还有一种情况是日志里啥都不报，但还原就是不动，这往往跟系统资源有关，比如磁盘 I/O 满了或者内存不够用。记住，日志是第一道防线，看不懂日志等于盲人摸象。
第二步：检查磁盘空间和文件系统状态。PG还原卡在99%，大概率是写文件的时候出了问题。用 看一眼，如果磁盘空间满了，恢复肯定卡住，因为 PG 写不了数据文件。但别只看根分区，数据目录所在的分区也得查。我遇到过一个案例，数据目录在 /data 下，根分区还有 50 GB 空间，但 /data 分区只剩几百兆，恢复写到一步时卡死。除了空间，还要看 inode，用 命令检查；inode 耗尽即使磁盘有空间也写不了新文件。另外，文件系统如果变成只读状态，也会导致还原卡住，这时 或 里会有硬件错误的提示。三步走：空间、inode、文件系统状态，缺一不可。
第三步：查一下是否有死锁或锁冲突。PG 的还原过程本质上是把数据写回磁盘，但如果有其他会话同时操作同一个表或索引，就可能产生锁冲突。用 看当前活跃的会话，重点关注 字段，如果显示 “LWLock” 或 “Lock”，那就是锁的问题。再用 视图查具体是哪把锁在阻塞。我碰到过一次，还原进程在重建索引时，另一个会话在跑慢查询，两者锁定了同一个表，结果双方互等，还原卡在99%。解决方案很简单：找到那个阻塞的会话，用 杀掉它，还原立马继续。但要注意，杀会话前最好确认它不是关键业务进程，别误伤。
第四步：检查网络和远程存储。现在很多企业用 NAS 或云存储来保存备份文件，还原时通过网络读取数据。如果网络不稳定或延迟高，还原进程可能在等待数据传输完成。用 或 测一下备份服务器到数据库服务器的延迟和丢包率。我见过一个奇葩案例，备份文件在 S3 上，还原时网络带宽被另一个大文件上传占满，导致数据读取超慢，进度条卡在99%。还有一种情况是备份文件本身不完整或损坏，PG 在还原到某一步时校验数据发现不一致，卡在那里报不了错。这时可以用 或直接对比文件哈希值来确认。别忽略网络，尤其是跨机房或跨云的还原场景。
第五步：看看数据库参数和系统资源。PG 的还原过程受很多参数影响，比如 、、 等。如果参数配置不合理，例如 设得太小，还原时频繁刷盘，磁盘 I/O 爆满，进度条就会卡住。用 或 看磁盘 I/O 和 CPU 使用率，如果磁盘等待时间（await）特别高，说明 I/O 成为瓶颈。还有一种情况是，还原过程中 PG 在应用 WAL 日志，如果 设置不对或归档模式未关闭，会导致还原效率极低。建议在还原前检查与 WAL 相关的参数。另外，系统资源如内存不足时，系统会开始 swap，恢复速度会降到冰点。用 看 swap 使用情况，如果发现大量 swap，赶紧排查内存压力。
回到开头那个朋友的案例，我帮他按这五步走了一遍。第一步看日志，发现没有明显报错；第二步查磁盘，数据分区空间还剩 15 GB，按理说够用；第三步查锁，发现有一个长时间运行的会话在锁着某个表；第四步检查网络，未发现异常；第五步看系统资源，内存使用率 95%，swap 已用了 2 GB。最终定位到问题：还原过程中，另一个会话在跑全表扫描，占用了大量内存和锁，导致还原进程卡住。杀掉那个会话后，还原在 10 分钟内顺利完成。他后来跟我说，早知道这五个步骤，就不用干等两个小时了。
PG数据库还原卡在99%，其实不是玄学问题，多数时候是资源竞争、锁冲突或磁盘空间在作怪。这五个排查步骤，从日志到磁盘，从锁到网络，再到系统资源，基本能覆盖 90% 以上的场景。只要按顺序来，别跳步，大概率能在半小时内找到根因。说一句，遇到问题别慌，卡住 99% 不代表还原失败，很多时候只是进程在等某个条件达成。冷静下来，按步骤排查，比重启一百次都管用。
