Linux系统下PostgreSQL多用户同时恢复不同数据库的可行方案咨询

嘿，这个问题我之前也帮团队排查过——PostgreSQL本身完全支持同时恢复不同的独立数据库，你遇到的串行阻塞情况，大概率是操作方式、锁冲突或者系统资源瓶颈导致的。下面分情况给你具体的解决方案：

1. 先确认你们用了正确的单库恢复姿势 #

如果你们是针对单个数据库做的备份（比如用pg_dump -Fc your_db生成的自定义格式备份），一定要确保各自的恢复命令只瞄准自己的目标库，别搞全局操作：

• 你的恢复命令可以是这样：

  pg_restore -d your_target_db -Fc your_db_backup.dump
  

• 同事的恢复命令对应改成他的目标库：

  pg_restore -d colleague_target_db -Fc colleague_db_backup.dump
  

这种情况下，两个恢复操作是完全独立的，理论上不会互相阻塞——除非你们的服务器资源实在不够用。

2. 避开全局操作带来的锁阻塞 #

如果你们的恢复流程里包含创建数据库的步骤（比如没提前建库，用了pg_restore --create参数），创建数据库的操作会短暂拿一个全局级别的锁，但这个锁一般握一下就放了，不会长时间卡着。要是真的出现长时间阻塞，得检查有没有其他全局操作在干扰：

• 恢复期间别执行DROP DATABASE、ALTER DATABASE ... RENAME这类改全局元数据的命令
• 别用pg_dumpall的全集群备份来恢复单个库——全集群恢复本身就是串行的，因为要按顺序恢复用户、表空间这些全局对象

3. 解决系统资源竞争的问题 #

如果是磁盘IO、CPU或者内存不够，导致两个恢复任务抢资源看起来像串行，那可以这么优化：

• 单个恢复任务用pg_restore的-j参数开并行恢复（只支持-Fc格式的自定义备份），比如开4个线程：

  pg_restore -d target_db -Fc backup.dump -j 4
  

  这个参数能让恢复更高效，减少资源占用的时间
• 调大PostgreSQL的maintenance_work_mem、work_mem配置，给恢复任务多分配点内存
• 把备份文件和数据库数据目录放在不同的磁盘上，避免IO打架

4. 排查并解除阻塞的锁 #

要是怀疑是锁卡住了，登录PostgreSQL跑个SQL看看谁在等锁：

SELECT 
  pid, 
  usename, 
  datname, 
  relation::regclass, 
  mode, 
  granted, 
  query
FROM pg_locks 
WHERE NOT granted;

找到阻塞同事恢复进程的那个锁，如果确实是没必要的锁，可以用SELECT pg_cancel_backend(pid);把对应的进程取消掉（注意别误杀自己的恢复进程哈）

内容的提问来源于stack exchange，提问作者Mani Ratna