如何限制pg_dump的内存占用？大PostgreSQL数据库迁移求助

嗨Christian，看到你在迁移超大PostgreSQL库时遇到的内存耗尽问题，太头疼了——我之前帮团队处理过120GB级别的PG迁移，刚好踩过类似的坑，给你几个实用的解决方案：

1. 换用pg_dump的目录格式（最推荐） #

你现在用的-Fc自定义格式会在内存中缓存较多数据来压缩和打包，这也是导致内存爆掉的核心原因之一。换成目录格式（-Fd），它会把每个表单独存成文件，写完一个就释放对应内存，不会堆积：

./pg_dump -Fd --no-acl --no-owner --host * --port 5432 -U * -d * -f F:/pg_backup_dir

这个格式不仅内存占用低，后续恢复还能并行处理，效率更高。如果需要压缩，之后可以把整个目录打包成zip或者tar.gz就行。

2. 分批导出核心大表 #

你的核心问题是那张130GB的大表，单独处理它能大幅降低内存压力：

• 先导出所有小表，排除大表：

  ./pg_dump -Fc --no-acl --no-owner --host * --port 5432 -U * -d * --exclude-table=your_big_table > F:/small_tables.dump
  

• 然后用COPY命令按分区键分批导出大表（比如按ID分段，假设你的大表有自增ID）：

  -- 先连到数据库执行这些COPY命令
  COPY (SELECT * FROM your_big_table WHERE id BETWEEN 1 AND 100000000) TO 'F:/big_table_part1.csv' WITH CSV HEADER;
  COPY (SELECT * FROM your_big_table WHERE id BETWEEN 100000001 AND 200000000) TO 'F:/big_table_part2.csv' WITH CSV HEADER;
  -- 重复直到覆盖所有5亿条数据
  

  恢复时先导入小表，再用COPY把各部分数据导回大表，最后重建索引就行。这种方式完全不会占用过多内存，因为每批数据写完就释放了。

3. 调整磁盘写入目标，避开慢存储 #

你现在把备份写到F盘，如果这是Azure的远程存储（比如Blob挂载），IO速度肯定跟不上网络传输速度，导致数据堆积在内存里。建议先写到VM的本地临时磁盘（通常是D盘，Azure VM的临时SSD，IOPS远高于远程存储），备份完成后再复制到目标存储：

# 先备份到临时磁盘
./pg_dump -Fd --no-acl --no-owner --host * --port 5432 -U * -d * -f D:/temp_pg_backup
# 再复制到F盘
robocopy D:/temp_pg_backup F:/pg_backup /E /COPYALL

4. 限制pg_dump相关的内存占用 #

pg_dump本身没有直接的内存限制参数，但可以通过两个方式间接控制：

• 服务器端调整：连接数据库时设置work_mem（降低排序/哈希操作的内存占用），比如：

  ./pg_dump -Fc --no-acl --no-owner --host * --port 5432 -U * -d * -o "-c work_mem=64MB" > F:/051418.dump
  

• Windows进程内存限制：用Windows的start命令以低优先级启动pg_dump，或者用Process Lasso这类工具限制pg_dump的内存上限，避免它耗尽系统内存。

5. 并行导出（适合多核VM） #

如果你的VM有多个VCPU，可以用-j参数启动并行导出，让多个进程分别处理不同的表，分散内存压力：

./pg_dump -Fc -j 4 --no-acl --no-owner --host * --port 5432 -U * -d * > F:/051418.dump

注意：并行导出需要PostgreSQL 9.3及以上版本，且确保服务器端能承受并行查询的负载。

建议你先试试目录格式或者分批导出大表，这两个方法解决过我遇到的类似问题，见效最快。

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