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

上周五晚上十点，电话把我从床上拽起来。朋友公司做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`单独导出全局角色，在目标库执行后再导入数据。命令是：

```bash
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迁移，硬生生折腾了快两周。事后复盘，工具都没选错，就是没人把整个迁移当成项目来管。方案、顺序、验证，缺一个就翻车。
![封面配图生成 (43).png](https://developer.qcloudimg.com/http-save/yehe-12362123/c1e819e20fdb6dd482dc2492ef68c4e2.png)
## 四套PostgreSQL迁移方案，怎么选

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

| 方案                   | 适用场景        | 停机窗口    | 数据量上限           | 复杂度 |
| -------------------- | ----------- | ------- | --------------- | --- |
| pg_dump + pg_restore | 跨服务器、小数据量上云 | 高，数小时起  | 百G以内            | 低   |
| pg_basebackup        | 同大版本物理迁移、灾备 | 中，分钟级   | 受磁盘/网络限制，无硬性上限  | 中   |
| 逻辑复制                 | 不停机迁移、跨云    | 极低，秒级切换 | 受WAL保留策略限制，需评估  | 高   |
| 专业迁移工具（KDTS等）        | 异构迁移、信创替换   | 可做到不停机  | 受迁移工具配置影响，无硬性上限 | 中   |

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

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

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

```bash
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，速度比逻辑导出快一个量级。代价是源和目标必须同大版本，而且迁移前要停写。停写是为了保证数据一致，复制过程中不允许有活跃事务。

```bash
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日志实时推过来。两边持续保持同步，切换窗口可以压到几秒，业务几乎无感。

```sql
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迁移任务，别急着敲命令，按这个框架走一遍。

| 步骤 | 判断维度 | 决策点 | 推荐方案 |
|---|---|---|---|
| 第一步 | 场景 | 同版本跨服务器 | pg_dump或pg_basebackup |
| | | 上云托管 | pg_dump+角色预创建 |
| | | 大版本升级 | pg_upgrade或逻辑复制 |
| | | 跨云/不停机 | 逻辑复制或专业工具 |
| | | 异构/信创替换 | 先KDMS评估再迁移 |
| 第二步 | 数据量 | 百G以内 | pg_dump |
| | | 百G到T级 | pg_basebackup或并行导出 |
| | | T级以上 | 物理复制或专业工具 |
| 第三步 | 停机窗口 | 能接受数小时 | pg_dump够用 |
| | | 分钟级 | pg_basebackup |
| | | 要求不停机 | 逻辑复制或KDTS增量 |
| 第四步 | 验证 | 对象对比 | 表/索引/序列数量 |
| | | 数据校验 | 核心表行数+抽样 |
| | | 业务回归 | 高频操作跑一遍 |

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

## PostgreSQL迁移避坑清单

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

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

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

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

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

## 写在最后

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

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

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


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

PostgreSQL迁移实战：200G库pg_dump翻车，四套方案选型与踩坑复盘

一次200G PostgreSQL迁移从翻车到成功的完整复盘。拆解pg_dump、pg_basebackup、逻辑复制、专业迁移工具四套方案的适用边界，覆盖数据一致性校验与信创场景下PostgreSQL迁移到金仓KES的实操路径。

数据库

PostgreSQL迁移常因方案与场景错配而失败。本文从200G大库pg_dump翻车案例出发，详解pg_dump、pg_basebackup、逻辑复制及KDTS等专业工具的适用条件、操作命令与避坑要点，并附四步决策框架和验证清单，助你选对方案、避免踩坑。

SQL数据库

对象存储

代码解释

数据迁移

数据同步

PostgreSQL

服务器

云托管

灾备

2026上云采购 | AI焕新·智启新局

postgres

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PostgreSQL迁移实战：200G库pg_dump翻车，四套方案选型与踩坑复盘-腾讯云开发者社区-腾讯云

PostgreSQL迁移实战：200G库pg_dump翻车，四套方案选型与踩坑复盘

PostgreSQL迁移实战：200G库pg_dump翻车，四套方案选型与踩坑复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐