PostgreSQL跨服务器数据迁移实战：从pg_dump到pg_restore全流程解析

1. 为什么选择pg_dump和pg_restore进行跨服务器迁移？

如果你手头有两台PostgreSQL服务器，需要把数据从A搬到B，你可能会想到很多方法：直接复制数据目录、用第三方同步工具，或者干脆写个脚本一条条记录导。但折腾一圈下来，你会发现PostgreSQL官方自带的pg_dump和pg_restore这对组合，才是真正省心又靠谱的“黄金搭档”。我这些年处理过不少数据迁移的活儿，从几个G的小库到上T的大库都搞过，实战下来这套方法最稳。

简单来说，pg_dump负责把数据库里的数据、表结构、索引、函数这些东西，打包成一个文件。这个文件就像是你给数据库拍了个完整的“快照”。然后，你把这个快照文件搬到另一台服务器上，用pg_restore这个工具，就能原原本本地把数据库“复活”出来。跨服务器迁移，无非就是中间加了个文件传输的步骤。这套方法有几个让我特别放心的地方：第一，它是官方工具，兼容性和稳定性没得说，不用担心数据格式出幺蛾子；第二，支持灵活备份，你可以选择全库备份，也可以只备份某个表或者只备份表结构；第三，恢复的时候可控性强，能选择并行恢复来提速，也能在恢复前先清理旧数据。

当然，市面上也有其他工具，比如逻辑复制或者一些商业软件。但对于大多数迁移场景，尤其是追求简单、直接、可控的团队，pg_dump和pg_restore的组合拳已经足够强大。它不挑环境，Linux、Windows都能用，而且命令清晰，出了问题也容易排查。接下来，我就带你走一遍完整的实战流程，从准备到验证，把每个环节的细节和容易踩的坑都讲清楚。

2. 迁移前的关键准备工作：磨刀不误砍柴工

在动手敲命令之前，花点时间把准备工作做扎实，能帮你避开迁移过程中一大半的坑。这一步的核心就八个字：心中有数，环境就绪。我习惯先列一张环境信息对照表，把源服务器和目标服务器的关键参数都理清楚。下面这个表格是我常用的格式，你可以直接套用：

这里我特别想强调一下版本一致的问题。虽然pg_dump和pg_restore在不同小版本间通常兼容，但大版本（比如从PostgreSQL 12迁移到15）可能会有语法或内部格式的差异。最稳妥的做法是保证目标服务器的PostgreSQL主版本号等于或高于源服务器。如果版本不一致，官方建议使用目标服务器版本的pg_dump工具去连接源库导出，这样能保证导出格式的兼容性。

除了版本，还有几个必须检查的点：