postgresql-9 至 postgresql-11 的数据迁移最优方案咨询

嘿，针对你几百GB的PostgreSQL 9到11的迁移需求，我来分享几个经过验证的高效方案——毕竟大库迁移最头疼的就是耗时和风险，咱们得选靠谱又省时间的路子：

1. 官方工具pg_upgrade（最快首选） #

这绝对是大库迁移的Top1选择，因为它是物理级别的升级，不需要导出导入数据，只是更新系统表和调整二进制文件格式，几百GB的库通常几个小时就能搞定，速度比逻辑导出快N个量级。

具体操作步骤大概是：

• 先安装好PostgreSQL 11，确保和你的9版本环境架构一致（比如都是64位），避免跨架构的兼容性问题。
• 停掉PostgreSQL 9的服务，一定要先做全量备份（比如用pg_basebackup），以防升级过程中出意外。
• 初始化PostgreSQL 11的数据库集群，但别启动服务。
• 运行pg_upgrade命令，指定旧版本和新版本的二进制路径、数据目录：

  pg_upgrade -b /usr/lib/postgresql/9.x/bin/ -B /usr/lib/postgresql/11/bin/ -d /var/lib/postgresql/9.x/main/ -D /var/lib/postgresql/11/main/
  

• 升级完成后，启动11版本的服务，运行配套的analyze_new_cluster.sh脚本更新统计信息，最后验证数据完整性（比如对比表行数、查询关键数据）。

注意：如果你的9版本是9.0及更早，可能需要先升级到9.6再升到11（pg_upgrade对跨大版本有一定限制）；另外可以加--link参数启用硬链接模式，速度更快且不占用额外磁盘空间，但风险稍高，务必提前备份。

2. 并行逻辑备份恢复（适合特殊兼容场景） #

如果因为某些原因没法用pg_upgrade（比如跨架构迁移、大量自定义函数/类型需要重新编译），那就用官方的pg_dump/pg_dumpall，比第三方工具靠谱且效率也能拉满。

核心技巧是并行导出恢复，充分利用多CPU和IO资源：

• 并行导出（以单个数据库为例）：

  pg_dump -j 8 -F d -f /path/to/backup_dir my_target_db
  

  其中-j 8表示用8个并行进程，-F d表示导出为目录格式（支持并行）。
• 并行恢复：

  pg_restore -j 8 -d my_new_db_11 /path/to/backup_dir
  

  几百GB的库如果IO性能不错，一天之内基本能完成。另外也可以拆分步骤：先导出表结构（-s参数）在11版本提前创建，再单独导出导入数据（-a参数），能进一步提升效率。

3. 流复制+主从切换（最小停机时间方案） #

如果你的业务不能接受长时间停机（比如只有几分钟的窗口），这个方案最适合：

• 先在PostgreSQL 11的服务器上初始化集群，开启WAL日志归档。
• 用pg_basebackup从9版本的主库拉取基础备份，配置流复制，让11版本的库作为从库同步数据。
• 等待从库完全同步后，把应用流量切换到11版本的库，然后停掉9版本的主库，将11版本的库提升为主库。

这个方案的停机时间只有切换流量的几分钟，数据一致性也有保障，只是操作稍微复杂一点，需要熟悉流复制的配置细节。

总的来说，优先选pg_upgrade，速度最快且风险可控；如果有特殊限制，就用并行逻辑备份；对可用性要求极高的话，就用流复制切换方案。

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