PostgreSQL 到国产库数据迁移方法论（评估→割接→回滚）

一句话机制：迁移不是"导一次数据"，而是一条「评估 → 准备 → 全量 → 增量 → 验证 → 割接 → 回滚」的七段式生命周期——前五段决定"能不能迁过去"，后两段（割接 Go/No-Go + 回滚预案）决定"出了事能不能退回来"。

七段式生命周期

评估 → 准备 → 全量 → 增量 → 验证 → 割接 → 回滚
KDMS    环境    导出    逻辑复制  校验    灰度    预案

任何一段缺失都不是完整迁移，尤其回滚预案——它是迁移方案里最容易被省略、却最不能省略的一段。

方案选择按数据规模：
规模方案
< 50GB pg_dump + ksql/psql 直接导入
50GB ~ 500GB pg_dump -j 并行导出 + KDTS / pg_restore
> 500GB KDTS 并行迁移（断点续传 + 大表拆分）
先数据、后约束：外键 / 索引一律先迁数据后建，避免逐行插入时反复校验约束拖慢迁移。
评估不可省（哪怕"同源"）：PG → 金仓属"同源"，但仍有差异——系统函数（pg_backend_pid → sys_backend_pid）、系统视图（pg_stat_activity → sys_stat_activity）、扩展插件（pg_partman/timescaledb/pglogical 不直接支持）。用自动化评估（如 KDMS）量化改造工作量，而非拍脑袋。
增量同步稳定是割接前置条件：双轨运行期持续监控复制延迟（lag），lag 持续 < 1s 且稳定 > 1 小时才具备割接资格。
割接 Go/No-Go 清单：全量 MD5 校验通过、增量 lag 达标、核心查询性能差异 < 20%、功能回归通过、回滚脚本 30 分钟内可完成、监控告警已配——任一未通过即 NO-GO，延期割接。
回滚三类型（按严重程度递进）：
- 应用层回滚（分钟级）：数据源切回源库，最快；
- 数据库层反向同步：目标库已产生增量时，反向导出增量回灌源库；
- 完整回滚：从备份恢复源库，用于数据破坏等极端情况。

序列值必须重置：迁移后所有 SERIAL 序列的 last_value 必须对齐到对应表 MAX(id)，否则目标库自增主键冲突。
导出必须 --no-owner --no-privileges：否则权限/属主迁移在目标库直接失败。
全量导入期可临时 wal_level=minimal 加速，导入后必须恢复 replica/logical——否则归档堆积或后续增量无法启动。
割接前必须验证回滚可在窗口内完成，没有回滚预案的割接是赌博。