在企业数据库演进中，PostgreSQL 到 PostgreSQL 的迁移与同步是非常典型的场景：版本升级、迁移上云、跨环境（开发→测试→生产）数据搬运、读写分离、异地灾备，甚至双活架构，都离不开一条稳定可靠的 PG→PG 复制链路。真正的难点通常不是"把数据拷过去"，而是"业务不停机、数据不丢失、结构不遗漏、增量能追上、出了问题能核对"。
本文结合 NineData 的 PostgreSQL → PostgreSQL 数据复制演示，按真实操作顺序，把前置条件、任务创建、对象选择、映射配置、预检查、全量与增量复制、实时监控与数据一致性对比完整走一遍，可作为一份可直接照做的迁移操作手册。
一、NineData 的 PG → PG 复制能解决什么问题
NineData 数据复制支持 PostgreSQL 到 PostgreSQL 之间的结构、全量数据和增量数据的高性能复制，核心能力可以概括为四点：
• 结构复制：只同步源数据源的库表结构，不同步数据；同构、异构数据源都适用，显著降低迁移门槛。
• 全量复制：通过智能数据分片实现行级并发批量复制，配合自研断点续传技术，保障大表与无主键表的数据准确性。
• 增量复制：支持全对象类型的 DML / DDL 增量同步，结合行级并发与热点合并，在全量完成后持续追平源端。
• 双向复制：多节点之间双向实时复制，用于构建异地多活架构；冲突处理策略可按业务选择。
这些能力组合起来，可以覆盖全量/增量数据复制、数据迁移、数据同步、数据集成，以及最关键的不停机无缝迁移等场景。
二、开始前必须完成的前置条件
演示视频在正式操作前，先用一页说明了"开始前必须完成的前置条件"。落到 PG → PG 链路上，主要是四类准备：数据源、版本、权限和源库参数，缺一不可。
1. 数据源与版本
• 录入数据源：源数据源、目标数据源都需要提前录入 NineData（创建 PostgreSQL 数据源）。
• 版本约束：必须满足"源数据源版本 ≤ 目标数据源版本"。例如源端为 PostgreSQL 12，则目标端可选 15、14、13、12；源端为 15 时，目标端只能是 15。
2. 账号权限（按复制类型区分）
• 结构复制：源端 CONNECT、SELECT；目标端 CREATE、USAGE on Schema（或等效 DDL 权限）。
• 全量复制：源端 CONNECT、SELECT；目标端 All Privileges on Schema、All Privileges on All Tables。
• 增量复制：源端需要 SUPERUSER（或经验证可满足逻辑复制预检查要求的等效高权限账号）；目标端 All Privileges on Schema、All Privileges on All Tables。
3. 源库关键参数（增量复制必需）
如需增量复制，需要在源库 postgresql.conf 中确认或调整以下参数；找不到配置文件时，可在 psql 中执行 SHOW config_file; 查看路径。
• wal_level：必须为 logical，用于输出逻辑复制所需的 WAL。可用 SHOW wal_level; 确认。
• wal_sender_timeout：设置为 0，禁用复制连接的超时中断（默认 60000 毫秒），避免空闲连接被误杀。
• max_replication_slots：必须大于 1（默认 10），决定可支持的最大复制槽数量。
• max_wal_senders：必须大于 1（默认 10），决定最大并发复制连接数。
4. 其他建议
• 全量初始化会占用源、目标一定的读写资源，建议在业务低峰期执行，并提前评估两端性能。
• 同步对象中的每张表最好都有主键或唯一约束，且列名唯一，否则可能重复同步相同数据。
三、创建复制任务：配置数据源与目标
在控制台左侧进入"数据复制 > 数据复制"，点击右上角"创建复制"，任务名称填写为 PG-PG-测试 之类有意义的名称（最多 64 个字符）。向导共五步：数据源与目标 → 选择复制对象 → 配置映射 → 预检查 → 启动任务。
关键参数怎么选
• 目标对象命名规则：保持与源一致（沿用源端命名）、全部转小写、全部转大写。跨库迁移时若两端命名规范不同，可用它统一风格。
• 复制方式：单向复制（源→目标，最常用）；双向复制（两端互相同步，用于双活，需要额外配置正向/反向复制类型，反向仅支持增量）。
• 复制类型：结构复制、全量复制（右侧开关为周期性全量复制）、增量复制。增量复制旁的操作类型配置，可以按需取消某类操作，取消后该类操作会在增量同步中被忽略。
• 复制规格：Micro / Small / Medium / Large / XLarge，规格越大复制速率越高；仅结构复制时不可选。
• 目标库同名对象处理策略（结构复制时）：预检查报错并停止任务 / 跳过并继续任务 / 删除对象并重建 / 保留结构并清空数据再覆盖写入。
• 目标表存量数据处理策略（全量复制时）：预检查报错并停止任务 / 忽略目标存量数据追加写入 / 清空目标存量数据重新写入。
• 目标表增量数据冲突处理策略（增量复制时）：运行时报错 / 不更新目标数据 / 更新目标数据。
• 触发器：默认禁用。目标端存在外键约束时开启触发器，可能导致复制任务失败，需谨慎。
四、选择复制对象与配置映射
第二步选择需要复制的内容。可以选择"全部实例"复制源库所有内容，也可以选择"自定义对象"，在源对象列表中勾选库表，点击 > 添加到右侧目标对象列表。若需要批量创建多条相同对象的链路，可通过"导入配置"下载模板、填好后上传。
第三步是配置映射。页面左侧是源端 → 目标端的库级映射，右侧逐表列出源表名、目标库名、目标 Schema、目标表名与操作。演示任务中共 21 个对象（7 张表 + 2 个函数），右侧每条记录都可点"映射与过滤"做更细的列级映射。
• 映射与过滤：可自定义源列同步到目标后的列名，并可设置数据过滤条件，仅符合条件的数据才会同步（例如 emp_no>=10005）。
• 批量配置：对大量表和字段统一定义大小写转换、前后缀添加、替换等规则，减少重复劳动。
• Object Owner：可指定对象的所有者；如需更新源/目标元数据，点右上角"刷新元数据"。
五、预检查：上线前的"全身体检"
点击"保存并预检查"后，系统会执行一系列检查。预检查是把风险挡在上线前的关键一步，常见检查项包括：
• 目标库同名对象存在性检查：检查待复制对象在目标数据库中是否已存在。
• 连接检查：检查源/目标数据源网关状态、实例是否可达、用户名及密码准确性。
• 权限检查：检查源库、目标库的账号权限是否满足要求。
• 目标库数据存在性检查：检查待复制对象在目标库中是否已存在数据。
• wal_level：检查源库 wal_level 是否为 logical。
• 复制参数：检查 max_wal_senders、max_replication_slots 是否满足复制连接/复制槽数量要求。
• 其他：检查目标库 extension 是否可用；校验待复制对象是否存在无主键或唯一键；校验源/目标实例是否处于只读模式。
演示中预检查弹出了"检测到拓扑中已存在环路可能会导致数据不一致"的提示------这类属于可识别的风险项，确认对本次迁移无影响后可以跳过；真正"失败"的检查项需要点"详情"排查原因，修复后"重新检查"，直到通过；"警告"项则视情况修复或忽略。
预检查通过后，可勾选"开启数据一致性对比"（支持全量对比、结构对比、增量对比），任务完成后自动校验两端数据一致，相当于给迁移加了一道验收。
六、启动任务：结构复制与全量复制
任务启动后进入"复制详情"，页面按"结构复制 / 全量复制 / 增量复制"三个阶段展示执行情况。演示任务中，7 个对象的全量复制全部"已完成"，可分别在"监控"查看指标、"限流设置"限制每秒写入行数、"日志"查看执行过程。
七、增量复制与实时监控
增量复制页签会展示 INSERT / UPDATE / DELETE / DDL 的实时计数、增量配置以及最关键的延迟指标。判断能否切换业务，主要看这几项：
• 延迟：读取延迟、复制延迟（毫秒）。当增量首次与源端一致且延迟为 0 秒时，说明目标端已追平，是切换流量的最佳时机。
• 吞吐：读取流量吞吐、写入流量吞吐，用于评估链路是否成为瓶颈。
• 同步位点管理：查看并修改读取位点/写入位点，用于特定运维场景；修改位点可能导致数据丢失，务必在授权测试环境或有备份回滚方案的维护窗口执行。
• 查看线程：查看线程号、正在执行的 SQL、提交响应时间、事件时间与状态，定位是否卡住。
• 限流设置：限制每秒写入目标端的速率（行/秒），保护目标库。
八、一致性保障与上线切换最佳实践
• 先对账再切：切换前必须满足两个条件：增量延迟为 0 秒，且数据对比通过。
• 数据对比：全量对比、结构对比、增量对比；发现不一致时可生成修复 SQL，直接复制到目标端执行修复。
• 留好退路：保留源库备份与回滚方案，切换窗口尽量选在业务低峰期。
• 控制冲击：全量阶段合理限流，避免把源/目标库压垮。
• 双活谨慎：双活场景用双向复制，并提前确定冲突处理策略，避免两端互相覆盖。
九、常见问题（FAQ）
Q1：PG → PG 迁移需要停机吗？ 可以。结构 + 全量 + 增量组合能实现不停机迁移，增量延迟归零后分钟级切换；但全量初始化仍会占用源/目标资源，建议低峰期执行。
Q2：增量复制必须把 wal_level 改成 logical 吗？ 是。源库 wal_level 必须为 logical；同时建议 wal_sender_timeout=0、max_replication_slots>1、max_wal_senders>1。
Q3：无主键表能迁移吗？ 可以。NineData 通过断点续传等技术保障无主键表的数据准确性；但仍建议每张表都有主键或唯一约束，避免重复同步。
Q4：源版本高于目标版本可以吗？ 不可以。要求源数据源版本小于等于目标数据源版本，跨大版本升级时尤其要注意。
Q5：预检查提示"存在环路"必须处理吗？ 它属于可能导致数据不一致的风险提示。确认对本次迁移无影响可以跳过，否则应先排查环路来源再继续。
Q6：延迟不为 0 能切流量吗？ 不建议。应等延迟降到 0 秒且数据对比通过后再切换，否则可能丢增量数据。
结语
一条可靠的 PG → PG 复制链路，等于"正确的前置条件 + 合理的复制类型 + 严格的预检查 + 可观测的增量延迟 + 数据一致性对比"。NineData 把这一整套流程产品化：从结构、全量到增量复制，从预检查到延迟监控，再到数据对比与修复，把"数据不丢、结构不差、切换可控"落成了可以照着点的步骤。对于正在做 PostgreSQL 版本升级、上云迁移或双活建设的团队，这是一条值得优先评估的路径。