PostgreSQL迁移最佳实践：四套方案对比与KES信创迁移路径

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

上周五晚上十点，电话把我从床上拽起来。朋友公司做PostgreSQL迁移，200G的库。pg_dump跑了一整夜没跑完，第二天业务直接卡死。他们问我第一句话，PostgreSQL迁移到底怎么搞才靠谱。我接手后重新捋了一遍，发现根子不在工具，而是顺序从一开始就反了。这次把从翻车到成功的完整过程写下来，方案、命令、报错、验证都讲透。希望你不用像我一样，熬夜踩完所有坑才明白。

PostgreSQL迁移，到底是什么

PostgreSQL迁移，是把PostgreSQL数据库从一个运行环境完整搬到另一个环境。结构、数据、权限、迁移后验证，四件事一个都不能少。很多人以为迁移就是把数据复制过去，其实权限和对象比数据更容易翻车。我这次就是栽在"以为数据对了就完事"上。PostgreSQL迁移的场景也很多：跨服务器搬机房、本地迁上云、大版本升级、跨云搬家，还有信创场景下迁到国产数据库。每种场景的约束不同，适合的方案完全不同。先搞清楚你是哪种，再谈工具，顺序不能反。

第一次翻车：pg_dump跑了一夜

朋友的原方案是pg_dump全量导出。命令本身没写错，错在没评估数据量。200G的库，pg_dump默认是单线程的，虽然可以用-j参数开启并行导出，但-j和--single-transaction不能同时使用，对于依赖事务一致性的场景限制较大。更要命的是，导出期间源库一直在写入，导出的数据本身就不一致。我当时第一反应不是换工具，是先量化问题。用SQL查了库大小和表数量，又评估了源库到目标库的带宽。结论是，纯pg_dump方案理论耗时超过十小时，停机窗口完全扛不住。

就算等它跑完，后面还有两颗雷。pg_dump不导出角色、表空间这些全局对象，目标库没有对应角色，导入时每条ALTER TABLE都会报错。跨环境迁移前，先用pg_dumpall -g单独导出全局角色，在目标库执行后再导入数据。命令是：

pg_dumpall -h 源库IP -p 5432 -U postgres -g > /tmp/global_objects.sql
psql -h 目标库IP -p 5432 -U postgres -f /tmp/global_objects.sql

先建好角色和表空间，再导表数据，顺序不能反。

另一个是序列值不同步，导入后新数据主键冲突，业务一写就炸。再加上上云场景没有superuser权限，很多在自建库能执行的命令，到云上直接报权限错误。这一套组合拳下来，一次看似简单的PostgreSQL迁移，硬生生折腾了快两周。事后复盘，工具都没选错，就是没人把整个迁移当成项目来管。方案、顺序、验证，缺一个就翻车。

四套PostgreSQL迁移方案，怎么选

重新规划前，我把PostgreSQL迁移的主流方案归成四类，先放一张对比表。

方案没有绝对好坏，只有合不合适。判断维度就三个：数据量、停机窗口、目标环境。数据量决定工具选型，停机窗口决定策略，目标环境决定迁移方式。下面逐个说清楚，各自什么时候用、坑在哪。小库和大库的选法完全不同，上云和自建也完全不同。别拿同一套模板套所有场景，不然早晚翻车。

pg_dump + pg_restore：小库够用，大库要命

pg_dump是PostgreSQL自带的逻辑备份工具，不用装额外软件。小数据量、能接受停机的场景，它比较省事。标准流程就两条命令，导出加导入。源端用pg_dump导出，-F c指定自定义格式，pg_restore才能读。目标端用pg_restore导入，-c参数会在导入前先drop已有对象，避免冲突。

pg_dump -h 源库IP -p 5432 -U postgres -d mydb -F c -f /tmp/mydb.dump
pg_restore -h 目标库IP -p 5432 -U postgres -d mydb -c /tmp/mydb.dump

小库这么玩没问题，大库就开始露馅。单线程慢只是其一，更麻烦的是它不搬角色和权限。跨环境迁移，记得先用pg_dumpall -g单独导出全局角色。目标库先建好用户，再导数据，不然一堆OWNER报错等着你。我这次翻车，一半原因就出在这。

pg_basebackup：物理级拷贝，快但挑剔

数据量几百G以上，pg_dump就不合适了。pg_basebackup做的是物理级备份，直接把数据目录完整拷过来。它不逐条解析SQL，速度比逻辑导出快一个量级。代价是源和目标必须同大版本，而且迁移前要停写。停写是为了保证数据一致，复制过程中不允许有活跃事务。

pg_basebackup -h 源库IP -D /var/lib/pgsql/data -U replicator -P -v -R

-R参数会自动生成standby配置，方便后续拉起为主库。迁移后记得改postgresql.conf和pg_hba.conf里的IP，不然起不来。它适合能接受分钟级停机、数据量大的同版本迁移。物理复制还有个隐藏要求，磁盘空间要够放两份数据。复制完成后，别忘了做一轮一致性检查。

切换前，在目标库执行SELECT setval('序列名', (SELECT last_value FROM 源库.序列名))，把序列值对齐。

逻辑复制：不停机PostgreSQL迁移的正解

业务24小时不能停，逻辑复制是目前比较成熟的方案。原理是源库建发布，目标库建订阅。全量同步完，增量变更通过WAL日志实时推过来。两边持续保持同步，切换窗口可以压到几秒，业务几乎无感。

CREATE PUBLICATION my_migration_pub FOR ALL TABLES;

CREATE SUBSCRIPTION my_migration_sub
  CONNECTION 'host=源库IP dbname=mydb user=replicator password=xxx'
  PUBLICATION my_migration_pub;

切换时停掉订阅，应用指到新库，基本秒级完成。但逻辑复制有几个前提必须满足。源库要开wal_level=logical，每张表要有主键或REPLICA IDENTITY。序列值不会自动同步，切换前要手动修正。DDL变更也不会自动复制，结构改动要提前在两边都执行。这套方案复杂度高，配置错了反而比pg_dump更麻烦。

专业迁移工具：异构和信创场景的兜底

前面三套都只解决PostgreSQL到PostgreSQL。异构迁移，比如迁到国产数据库，纯手工方式效率太低。这时候专业迁移工具是正解。以金仓数据迁移工具KDTS为例，流程是评估、结构迁移、全量迁移、增量同步四步。先扫一遍源库的兼容性，哪些能自动迁、哪些要改造，心里先有数再动手。这一步做扎实，后面能省大量返工时间。

一次真实复盘：PostgreSQL迁移到KES

这次复盘里，有个客户是从PostgreSQL迁到KES。迁移前先用KDMS做兼容性评估，扫描源库生成报告，标记出需要改造的对象。评估结果显示，大部分表和索引可以直接迁移，主要改造点在存储过程和个别数据类型。这一步很关键，它把未知变成已知，返工风险提前排掉。评估报告就是后续迁移的作战地图。

结构迁移由KDTS自动转换DDL，处理数据类型映射。全量迁移走并行导出导入，支持断点续传，几百G的库不用从头再来。如果业务不能停，还有增量同步兜底，靠日志捕获变更持续推送到目标端。这一套组合下来，整个PostgreSQL迁移从评估到切换，比纯手工方案省了大量时间。评估、迁移、同步三个环节可以分阶段执行，每一步都能独立验收。

增量同步这块，金仓还有一款异构数据同步软件Kingbase FlySync，简称KFS。它主打无侵入式同步，不需要改源库结构。金仓社区2025年6月分享过一个三甲医院案例，用KFS做增量数据同步，实现医院核心系统数据迁移轻装上阵。这种场景下，业务侧几乎无感，停机窗口压缩到极小。如果你正在做医疗、金融这类不能停的业务，这条值得重点看。

PostgreSQL迁移决策框架：四步走

面对一个具体的PostgreSQL迁移任务，别急着敲命令，按这个框架走一遍。

信创场景还要多问一句：目标库的合规要求、生态兼容性、后续运维成本。比如迁到KES这类国产数据库，要提前确认组件和周边工具是否兼容。这些维度，往往比单纯比性能更重要。数据库迁移不是一次性的搬运，迁过去之后要跑好几年。目标库能不能扛住业务增长，团队熟不熟悉，都要提前想清楚。

PostgreSQL迁移避坑清单

最后把这次踩的坑总结成几条，每一条都是用熬夜换来的教训。

备份一定放独立存储。备份文件和源库放同一台机器，磁盘一出问题，备份跟着全没了。放到另一台机器或对象存储上，心里才踏实。我见过不止一次，迁移没出事，备份先出事。这也是迁移前最容易省的一步。

迁移前先跑兼容性评估。尤其异构迁移，不要上来就导数据。用工具扫一遍，看清哪些能自动迁、哪些要手工改。心里有数再动手，能省大量返工。KDMS这类评估工具的价值，就是帮你把未知变已知。

序列值必须手动修正。逻辑复制不搬序列，pg_dump默认参数也可能滞后。切换前把所有序列查一遍，取较大值修正。不然业务一写就主键冲突，线上直接炸。这个坑，很多教程都不写。

迁移完成不等于成功。对象对比、数据校验、业务回归，三步缺一不可。我见过太多人数据搬完了，权限没跟上，应用直接报错。数据对得上，不代表业务能跑起来。别省最后这步验证，验证才是成功与否的裁判。

写在最后

这次PostgreSQL迁移复盘，核心体会是：工具永远是第二位的，第一位是搞清楚场景。小库用pg_dump省心，大库上物理复制，不停机选逻辑复制。异构信创场景，交给专业工具加评估流程。顺序对了，后面才不慌。

如果是信创场景下的PostgreSQL迁移，金仓KES配合KDMS、KDTS、KFS这套工具链，兼容性评估和迁移执行都有成熟方案兜底。评估、迁移、增量同步、数据校验，一条龙都有人替你考虑，能少踩很多坑。我自己跑完这套流程，第二次再做迁移就顺多了。以前总担心迁完出幺蛾子，现在敢先做评估再动手了。大家在PostgreSQL迁移时还踩过什么坑？评论区聊聊，咱们互相避雷。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋