Phi模型下载与安装详细教程（资料版1102940223）
2026-11-02 3468825
2026-11-02 0
17或18迁往19需要主版本升级，不能让新程序直接启动旧目录。有停机窗口且环境变化少，可先评估pg_upgrade；希望重新装载数据，可用导出恢复；只能短暂停写，则考虑逻辑复制，但收尾与切换更复杂。
17可以直接升19，不必先迁到18。不过中间版本的兼容性变化仍要阅读，应用和扩展是否适配也需要单独测试，工具成功搬数据不能替代这一步。
| 方式 | 适合情况 | 主要代价 |
|---|---|---|
| pg_upgrade | 整体升级、平台兼容、有维护窗口 | 需要停机；扩展要有适配新版本的程序；选错模式会影响退回旧库 |
| dump/restore | 数据规模可控、重建环境、筛选对象 | 导出恢复及索引重建时间，切换前需处理新增写入 |
| 逻辑复制 | 大部分迁移工作要在线完成、需要较短停写窗口 | 同时维护新旧两套库，还要处理漏复制的对象及最后切换 |
任何方案都不能先假定零停机。持续复制之后，仍需停止旧端写入、让目标处理完剩余修改，核对状态，再交接连接和写入权限。
pg_upgrade 通过新建系统目录、复用或迁移用户数据文件来加快主版本升级。应使用 19 的 pg_upgrade，并准备新旧两套程序、数据目录和兼容的新集群配置。先执行检查，不要直接进入正式迁移：
路径只是示例。源版本是 17 时，就填写 17 对应的路径。不要只在一个空库里检查通过：真实业务用到的扩展、表空间、登录方式和目录权限，也必须一起检查。
默认复制模式需要额外空间；link 模式减少复制，但新库开始写入后不能把旧目录当作独立回退副本；clone 是否可用取决于文件系统；swap 会改变旧目录。不能只因某种方式快，就在没有恢复方案时采用它。
完成升级后，要执行工具输出的后续处理，核实扩展更新、统计信息和索引要求，并验证备库、归档、备份及监控。命令退出成功，只代表迁移阶段完成。
导出恢复会重新创建数据库对象和数据，便于更换存储布局或只迁移部分内容，但大表装载、索引与约束构建可能耗时很长。建议使用目标主版本的导出工具读取旧服务器。
目标数据库需提前按方案创建。单库 pg_dump 不包含集群级角色、表空间等全部信息，应另行处理全局对象、权限和外部文件。实际备份还要验证扩展、编码、排序规则及恢复日志。
pg_dump 可以在业务运行时取得一致性快照，但快照之后的新增写入不会自动进入备份。若只采用导出恢复，必须把最终停写和完整导出安排在切换流程中，否则迁过去的只是旧时间点数据。
通常先建立目标结构和必要对象，再进行初始同步与持续复制。旧库继续服务期间，要观察复制槽积压的 WAL 日志、目标库追赶速度、磁盘余量和错误日志，防止复制落后拖垮源库磁盘。
切换时冻结结构变更和旧库写入，确认最后一笔业务修改已经到达目标库并处理完成，再核对数据及序列状态。DDL、权限和大对象等内容不能假定会随着表数据自动完成迁移。
目标库是19，不会使17/18源端自动支持19新增的序列同步。旧发布端的序列要另做计划，也不能仅凭复制延迟小就让新库接收写入。
演练至少要测出完整用时、实际停写多久、最高额外磁盘用量，以及失败后恢复所需时间。数据与扩展权限越接近生产，测量越有参考意义。
几百GB且允许夜间停机的库，pg_upgrade可能更省事；停写要求严格并需要跨平台时，可评估逻辑复制；小库也可采用导出恢复。最后应选择团队能完整执行、也知道怎样恢复的方案。