非云部署PostgreSQL迁移至AWS数据库可否使用dblink及最优方案咨询

一、dblink实现迁移的可行性 #

可以通过dblink完成该迁移操作。dblink是PostgreSQL原生自带的跨库连接插件，支持在两个独立的PG实例之间直接执行跨库查询、数据写入，适配同构PG实例的全量数据迁移场景，更适合数据量100GB以内、可接受数小时以内停机窗口的非核心业务。

核心操作步骤 #

• 在源端或目标端PG实例安装dblink插件：

  CREATE EXTENSION IF NOT EXISTS dblink;
  

• 完成网络配置：确保本地旧库与AWS新库的防火墙、安全组放开5432端口的访问权限，建议通过AWS VPN、专线传输数据，避免公网传输的安全风险和性能波动
• 执行数据迁移：可在目标端执行语句直接拉取源端数据，示例如下：

  INSERT INTO 目标表 SELECT * FROM dblink(
  'host=源库IP port=5432 dbname=源库名 user=用户名 password=密码',
  'SELECT * FROM 源表'
  ) AS t(字段1 类型, 字段2 类型, ...);
  

• 迁移完成后逐表比对行数、关键字段哈希值，验证数据一致性

方案优缺点 #

• 优势：无需额外部署工具，操作门槛低，小表全量迁移效率高
• 劣势：大表传输容易出现连接超时中断问题，不支持增量同步，停机窗口长，不适合TB级以上库或者核心业务迁移

二、行业通用的PostgreSQL迁移最佳实践 #

根据业务停机容忍度、数据库规模的不同，常用方案分为三类：

1. 可接受短停机窗口（数小时内）的全量迁移 #

• pg_dump/pg_restore原生工具：这是最通用的轻量迁移方案，适配1TB以内的PG库。源端执行pg_dump -Fc -j 并行数 -f 备份文件.dmp 源库名生成压缩格式的备份文件，传输到目标端后执行pg_restore -d 目标库名 -j 并行数 备份文件.dmp完成恢复，支持并行处理，稳定性远高于dblink，不会出现大表传输中断问题。
• AWS DMS迁移服务：AWS官方提供的托管迁移工具，原生支持同构PG迁移，无需自行部署维护，支持全量+增量自动同步，可将停机窗口压缩到分钟级，自带数据一致性校验能力，适配迁移到AWS云环境的场景。

2. 近零停机要求（分钟级/秒级停机）的核心业务迁移 #

• PG原生逻辑复制：PG 10及以上版本自带的能力，先完成全量基线数据同步，再实时同步源端的增量事务，业务仅需在最终流量切换时做秒级中断即可完成迁移。需要提前将源端的wal_level参数调整为logical，预留足够的WAL日志存储空间。
• pglogical开源插件：比原生逻辑复制支持更丰富的场景，包括跨大版本PG迁移、部分表选择性同步、DDL操作同步等，适配有定制化同步需求的业务。

3. 超大规模（10TB以上）数据库迁移 #

• 物理备份恢复+流复制追平：先对源库做全量物理备份，恢复到AWS目标端后，通过流复制追平源端的增量数据，待两端数据完全一致后完成流量切换，迁移速度是逻辑类方案的3~5倍，要求源端和目标端的PG大版本、CPU架构保持一致。

迁移前置注意事项：

1. 提前完成源端、目标端的版本兼容性校验，排查数据类型、自定义函数、SQL语法的兼容问题
2. 所有迁移操作必须先在测试环境完成一次完整演练，统计迁移耗时、验证业务功能可用性
3. 迁移完成后必须做全量数据一致性校验，同时压测验证目标库的性能满足业务要求
4. 迁移完成后至少保留源端7天的全量备份，避免迁移故障导致数据丢失

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