1. 课程导入与迁移升级全景

PostgreSQL 的数据迁移与版本升级，表面上是“把数据从 A 搬到 B”或“把 14 升到 16”，但真正决定成败的，往往不是某一条命令，而是对目标、场景、风险与回滚路径的整体判断。本课程的核心目标，是让读者建立一条从评估到实施再到回滚的完整工程视角：既能看懂迁移升级在做什么，也能在真实环境中判断“该不该做、怎么做、出问题怎么办”。

一、先分清两件事：数据迁移与版本升级

数据迁移关注的是数据与对象的位移，典型形态包括：同版本跨实例搬迁、异构数据库（如 Oracle、MySQL、SQL Server）迁入 PostgreSQL、上云或下云、分库分表后的重新分布。它的核心矛盾是“数据一致性”和“停机窗口”。版本升级关注的是同一套数据在 PostgreSQL 大版本之间的演进，例如 12→15、14→16，核心矛盾是“系统目录与存储格式不兼容”以及“应用兼容性”。两者经常叠加出现：上云时顺便把 12 升到 16，就是一次“迁移+升级”的复合工程。

理解这一点很关键：迁移可以用逻辑复制、逻辑导出、外部表等方式绕开物理格式差异；而大版本升级，PostgreSQL 明确不支持原地二进制替换数据目录，必须走 pg_upgrade、逻辑复制或导出导入三条路之一。把这两类问题混为一谈，是很多项目排期失真的根源。

二、典型场景与选型直觉

不同场景对应不同的技术路线，选型时先问三个问题：停机窗口有多长？数据量有多大？源和目标是否同版本、同平台？

• 小库、可停机：pg_dump/pg_restore 最直接，逻辑对象清晰，便于裁剪。
• 大库、停机窗口极短：逻辑复制（pglogical 或原生 publication/subscription）先全量再增量，最后短暂切换。
• 同平台大版本升级、可接受分钟级停机：pg_upgrade 配合 --link 模式，速度最快，但要求新旧集群在同一主机或共享存储上。
• 异构数据库迁入：通常先用 ora2pg、pgloader 等工具做结构与数据转换，再配合逻辑复制追平增量。

这里没有“最好”的工具，只有与约束匹配的方案。例如一个 2TB 的库，若停机窗口只有 30 分钟，pg_dump 基本不可行；而 pg_upgrade --link 虽然快，却要求新旧数据目录在同一文件系统，且升级后旧集群不可再启动，必须提前做好备份。

三、风险矩阵：把“可能出事”变成“可管理”

迁移升级的风险不是均匀分布的，它集中在几个关键节点上。下面这张图把典型风险按“发生阶段”和“影响面”组织起来，帮助读者在项目开始前就锁定重点防护对象。

图中把风险按“评估—准备—切换—验证/回滚”四个阶段铺开，并用底部色带表示影响面。可以看到，真正会造成严重数据丢失的风险，往往集中在切换与回滚阶段；而评估阶段的疏漏，则会在后期以“兼容性报错”的形式集中爆发。因此，评估不是走过场，而是把后期返工成本前移的关键动作。

四、从评估到回滚：一条完整的工程链路

一个可执行的迁移升级项目，通常包含以下闭环动作，读者可以把它当作检查清单使用：

1. 资产盘点：统计数据库数量、总数据量、最大单表、对象类型（表、索引、视图、函数、触发器、扩展）、外部依赖（FDW、逻辑复制槽、定时任务）。
2. 兼容性评估：确认源与目标版本差异，重点检查 pg_upgrade 不支持的对象、已废弃参数、扩展可用性。例如 12→16 需关注 recovery.conf 已移除、pg_stat_statements 需同步升级。
3. 方案选型与演练：根据停机窗口和数据量选择工具，并在预生产环境完整跑一遍，记录全量耗时、增量延迟、切换耗时。
4. 正式实施：按“备份→初始化目标→全量→增量→停写→追平→校验→切换”的顺序推进，每一步都有明确的进入和退出条件。
5. 验证与回滚：校验行数、关键业务查询、约束与序列；若失败，按预案切回旧库，并保留现场用于复盘。

五、学习路径与心态

本课程后续会沿着“评估方法 → 工具实操 → 切换策略 → 回滚与复盘”逐步展开。建议读者在学习时始终带着三个问题：我的停机窗口是多少？我的数据量有多大？我的回滚路径是什么？ 这三个问题没有标准答案，但它们决定了每一次技术选型的方向。迁移升级不是一次性的脚本执行，而是一次需要被设计、被演练、被验证的工程活动。把风险想在前面，把回滚握在手里，才是这门课真正想传递的工程习惯。