PostgreSQL 17/18升级19怎么选？三种迁移方式对比

17或18迁往19需要主版本升级，不能让新程序直接启动旧目录。有停机窗口且环境变化少，可先评估pg_upgrade；希望重新装载数据，可用导出恢复；只能短暂停写，则考虑逻辑复制，但收尾与切换更复杂。

17可以直接升19，不必先迁到18。不过中间版本的兼容性变化仍要阅读，应用和扩展是否适配也需要单独测试，工具成功搬数据不能替代这一步。

一、先按停机要求和迁移目的选择

任何方案都不能先假定零停机。持续复制之后，仍需停止旧端写入、让目标处理完剩余修改，核对状态，再交接连接和写入权限。

二、pg_upgrade：先检查，再决定文件迁移方式

pg_upgrade 通过新建系统目录、复用或迁移用户数据文件来加快主版本升级。应使用 19 的 pg_upgrade，并准备新旧两套程序、数据目录和兼容的新集群配置。先执行检查，不要直接进入正式迁移：

路径只是示例。源版本是 17 时，就填写 17 对应的路径。不要只在一个空库里检查通过：真实业务用到的扩展、表空间、登录方式和目录权限，也必须一起检查。

默认复制模式需要额外空间；link 模式减少复制，但新库开始写入后不能把旧目录当作独立回退副本；clone 是否可用取决于文件系统；swap 会改变旧目录。不能只因某种方式快，就在没有恢复方案时采用它。

完成升级后，要执行工具输出的后续处理，核实扩展更新、统计信息和索引要求，并验证备库、归档、备份及监控。命令退出成功，只代表迁移阶段完成。

三、dump/restore：用可恢复的备份做迁移

导出恢复会重新创建数据库对象和数据，便于更换存储布局或只迁移部分内容，但大表装载、索引与约束构建可能耗时很长。建议使用目标主版本的导出工具读取旧服务器。

目标数据库需提前按方案创建。单库 pg_dump 不包含集群级角色、表空间等全部信息，应另行处理全局对象、权限和外部文件。实际备份还要验证扩展、编码、排序规则及恢复日志。

pg_dump 可以在业务运行时取得一致性快照，但快照之后的新增写入不会自动进入备份。若只采用导出恢复，必须把最终停写和完整导出安排在切换流程中，否则迁过去的只是旧时间点数据。

四、逻辑复制：停写短，准备工作更多

通常先建立目标结构和必要对象，再进行初始同步与持续复制。旧库继续服务期间，要观察复制槽积压的 WAL 日志、目标库追赶速度、磁盘余量和错误日志，防止复制落后拖垮源库磁盘。

切换时冻结结构变更和旧库写入，确认最后一笔业务修改已经到达目标库并处理完成，再核对数据及序列状态。DDL、权限和大对象等内容不能假定会随着表数据自动完成迁移。

目标库是19，不会使17/18源端自动支持19新增的序列同步。旧发布端的序列要另做计划，也不能仅凭复制延迟小就让新库接收写入。

五、最终选择，用演练数据说话

演练至少要测出完整用时、实际停写多久、最高额外磁盘用量，以及失败后恢复所需时间。数据与扩展权限越接近生产，测量越有参考意义。

几百GB且允许夜间停机的库，pg_upgrade可能更省事；停写要求严格并需要跨平台时，可评估逻辑复制；小库也可采用导出恢复。最后应选择团队能完整执行、也知道怎样恢复的方案。