PostgreSQL升级过程中如何减少磁盘空间占用？

嗨，我来帮你捋捋这个问题——你用docker-compose exec db pg_dumpall -U app | docker-compose exec -T db16 psql -U app这种管道直连的方式升级PostgreSQL时，遇到磁盘空间不够的情况，其实挺常见的。咱们先搞清楚为啥明明看起来剩余空间够却不够用：这种纯文本SQL的导入方式，新数据库不仅要存下和原库一样的123G数据，导入过程中还会生成大量的WAL（预写式日志）、临时索引文件，甚至中间事务的临时数据，这些加起来很容易吃掉额外的几十G空间，超了你的161G剩余也不奇怪。

下面给你几个实用的优化方法，能有效减少磁盘占用：

• 给导出导入流加压缩：pg_dumpall导出的纯文本SQL压缩率极高（尤其是有重复数据的库，能压到原大小的1/3甚至更小），咱们在管道里加压缩和解压步骤，既能减少传输过程中的内存占用，也能降低新库导入时的临时数据压力。修改后的命令大概是这样：

  docker-compose exec db pg_dumpall -U app | gzip | docker-compose exec -T db16 sh -c 'gunzip | psql -U app'
  

  要是你的CPU性能足够，用xz压缩率更高，就是速度会慢一点，按需选择就行。

• 临时调整新PostgreSQL的WAL配置：默认的WAL配置会保留不少日志，导入时会疯狂占空间。你可以先进入新的db16容器，修改postgresql.conf里的几个参数：

  • 把wal_level改成minimal（这是最精简的日志级别，只保证崩溃恢复）
  • 设archive_mode = off（关闭日志归档，导入完成后再打开）
  • 调小max_wal_size，比如改成64GB（默认可能是100GB以上，减少日志文件的累积）
    修改完重启新数据库服务，导入完成后记得改回原来的配置，避免影响后续的备份和恢复功能。

• 改用自定义格式导出+并行导入：别用pg_dumpall导出纯文本了，改用pg_dump的自定义格式（-Fc参数），它自带压缩，而且能用pg_restore并行导入，效率更高还省空间。步骤大概是：

  1. 先导出原数据库（如果是多数据库，循环导出每个库）：

     docker-compose exec db pg_dump -U app -Fc -f /tmp/db_dump.sqlc [你的数据库名]
     

     要是想一次性导出所有库，用pg_dumpall -Fc也可以。
  2. 把导出的文件复制到新容器里，然后用pg_restore并行导入：

     docker-compose exec -T db16 pg_restore -U app -d [你的数据库名] --jobs=4 /tmp/db_dump.sqlc
     

     --jobs后面的数字根据你CPU核心数来设，比如4核就设4，这样能加快导入速度，同时减少临时文件的生成。

• 先清理原数据库的冗余数据：如果还没开始升级，先给原数据库做个全面清理：

  • 运行VACUUM FULL回收表的空闲空间（注意这个会锁表，要在业务低峰期做）
  • 删除过期的历史数据、无用的索引、临时表
  • 清理pg_stat_statements这类扩展的冗余记录
    这样原数据库的实际占用空间会变小，导出的文件也会更小，自然能减少新库的导入压力。

最后提醒一下，不管用哪种方法，导入前最好先给新数据库做个基础备份（比如用pg_basebackup），以防中途出问题能快速回滚。

备注：内容来源于stack exchange，提问作者gucki