Oracle 到 MySQL、PostgreSQL 的持续同步怎么做？ 以 NineData 为例拆解异构复制链路

Oracle 到 MySQL、Oracle 到 PostgreSQL，这类问题在数据库迁移和数据库替换项目里很常见。真正进入实施阶段后，难点通常不只是“把数据导到目标端”，而是源端 Oracle 仍在持续写入时，目标端如何完成结构初始化、全量复制、增量追平、同步延迟观察，以及切换前的数据核验。下面结合一条常见的异构复制链路展开说明，并以 NineData 的任务方式作为示例，拆解这类项目中几个更关键的实施环节。

为什么这类任务通常不只是一次性导数

第一次做 Oracle 异构迁移时，很多团队会先按下面的顺序理解：

• 先迁结构
• 再迁全量数据
• 最后补增量

这个思路本身没有问题，但项目进入生产阶段后，关注点往往会发生变化：

• Oracle 源端还在持续写入，增量链路要能稳定接住
• 全量初始化可能持续较长时间，目标端要继续追平
• Oracle 和 MySQL、PostgreSQL 之间存在数据类型差异
• 切换前需要判断目标端是否已经接近源端状态
• 任务运行正常，不代表结果已经完成核验

所以这类项目讨论到后面，重点通常不再只是“数据能不能迁过去”，而是“这条异构同步链路能不能稳定运行并便于后续维护”。

一条常见的实施主线

Oracle 到 MySQL 和 Oracle 到 PostgreSQL，虽然目标端不同，但整体实施路径通常比较接近，可以按下面这条主线理解：

• 接入源端 Oracle 和目标端数据库
• 准备 Oracle 增量复制所需条件
• 创建结构、全量、增量一体的复制任务
• 观察任务延迟和运行状态
• 在切换前补充数据比对
• 为持续运行的任务配置告警

如果把这类项目理解成“初始化 + 持续追平 + 结果核验”的组合，会比把它看成一次性导数更贴近实际情况。

先接入源端和目标端

复制任务建立之前，通常要先完成数据源接入。这里的核心不是目标库具体是哪一种，而是把源端 Oracle 和目标端 MySQL、PostgreSQL 放到同一条后续链路里

图1：数据源接入入口

接入时通常会填写这些信息：

• 数据源类型
• 连接地址和端口
• 数据库账号与认证信息
• 网络接入方式或所属地域

图2：配置 Oracle 源端和目标端数据库

这一层准备的意义在于，后面的结构复制、全量初始化、增量同步和数据比对，都会建立在已接入的数据源之上。

第二步：提前确认 Oracle 的增量条件

如果任务只是一次性迁移，全量完成后就结束，那链路设计会简单很多。 但如果目标是“迁移期间源端继续写，目标端持续追平”，那 Oracle 的增量复制条件就需要提前确认。

通常会优先看这几项：

• Oracle 是否已经启用归档模式
• 是否已经开启附加日志
• 用于复制的账号权限是否满足要求

这几项直接关系到增量链路能否建立起来。对于 Oracle 作为源端的异构复制项目来说，这通常属于前置准备，而不是后面再补的步骤。

第三步：把结构、全量、增量放进同一条复制任务

数据源和源端条件准备好之后，下一步就是创建复制任务。

图3：进入数据复制并新建任务

在任务配置阶段，通常会涉及这些信息：

• 任务名称
• 源端 Oracle
• 目标端 MySQL 或 PostgreSQL
• 目标数据库
• 复制范围和复制类型

图4：配置结构复制、全量复制和增量复制

如果目标是持续同步，常见做法通常是同时勾选：

• 结构复制
• 全量复制
• 增量复制

这样做的意义在于，初始化和后续追平不是拆成几套分散方式处理，而是放在一条连续链路里完成。对 Oracle 到 MySQL、Oracle 到 PostgreSQL 这类项目来说，这种方式更容易支撑后续切换准备。

第四步：不要只看任务创建成功，还要持续看延迟

复制任务启动之后，通常会先跑全量，随后进入增量阶段。 这时候判断任务状态，不能只看“是否创建成功”，更需要看源端和目标端之间的同步延迟。

图5：查看任务延迟和运行状态

如果延迟持续接近 0，通常说明：

• Oracle 新产生的变更已经较快同步到目标端
• 目标端正在逐步追平源端状态
• 切换窗口会更容易评估

对于 Oracle 到 PostgreSQL、Oracle 到 MySQL 这类异构链路来说，延迟观察的价值很直接，因为切换能否推进，往往不仅取决于任务有没有建起来，还取决于目标端是否已经足够接近源端。

第五步：同步完成，不等于结果已经确认

异构同步项目里，一个常见误区是把“任务正常运行”直接等同于“数据已经一致”。 但 Oracle 到 MySQL、Oracle 到 PostgreSQL 这种跨数据库类型的同步，很多团队在真正切换前，仍然会补一轮数据核验。

NineData 在这一层可以继续承接数据比对动作。

图6：进入任务详情查看链路状态

图7：发起数据比对任务

图8：查看比对结果

图9：重新校验最新增量数据

数据比对通常会帮助团队确认这些问题：

• 目标端关键表的数据是否完整
• 当前同步结果是否已经追平
• 最新增量是否已经同步到位
• 切换前是否具备额外的验证依据

从实施角度看，这一步并不是额外附加的动作，而是异构同步项目里比较常见的一层确认机制。

第六步：持续运行的链路，通常还要补上告警

很多 Oracle 替换项目并不是当天建链路、当天切换完成。 更常见的情况是，链路会运行一段时间，用来支撑灰度验证、业务核查和低峰切换。

这种情况下，任务告警就会变得比较重要。

图10：配置任务告警

告警通常会用在这些位置：

• 任务异常时及时发现
• 延迟升高时尽快定位
• 持续运行期间便于统一维护

所以对于 Oracle 到 MySQL、Oracle 到 PostgreSQL 这类需要跑一段时间的同步链路来说，告警更像是持续运维的一部分，而不只是补充功能。

哪些场景更容易考虑这种方式

如果团队正在处理下面这些任务，NineData 往往比较容易进入讨论范围：

• Oracle 下线或替换项目
• Oracle 到 MySQL 的业务迁移
• Oracle 到 PostgreSQL 的数据库替换
• 迁移期间源端仍持续写入，需要目标端长期追平
• 切换前希望持续观察延迟并补充数据校验
• 多条异构同步任务希望统一管理

如果只是一次性的导数任务，脚本或迁移工具在一些场景下也可以完成工作。 但如果项目要经历“初始化、追平、观察、核验、切换”这几个阶段，那么平台化方式通常更适合承接整条链路。

Oracle 到 MySQL、PostgreSQL，什么时候更像“同步”而不是“迁移”？

如果源端 Oracle 在项目期间还持续写入，这类任务通常就不只是一次性迁移，而更接近持续同步。因为目标端除了完成初始化，还需要继续接收后续增量，并为切换前验证预留时间。

Oracle 做增量复制前，要先确认什么？

通常会先看这几项：

• 是否启用归档模式
• 是否开启附加日志
• 复制账号权限是否满足要求

这些前提一般会直接影响增量链路能否正常建立。

为什么任务运行正常后，还要再做数据比对？

因为“任务在运行”不等于“结果已经完全对齐”。 在 Oracle 到 MySQL、Oracle 到 PostgreSQL 这类异构链路里，切换前补一轮数据核验，通常更有助于确认目标端状态。

延迟接近 0，是不是就可以切换？

延迟接近 0 往往说明目标端已经比较接近源端状态，但是否切换，通常还要结合业务窗口、关键表核验结果和应用侧准备情况一起判断。延迟是重要信号，但不是唯一依据。

一次性迁移，还需要这套方式吗？

如果只是短期、单次的数据搬迁，脚本和迁移工具在很多场景下已经够用。 如果任务要持续运行一段时间，还要观察延迟、处理异常、补做数据核验，那么把复制链路放到统一平台里管理会更方便。

文中为什么用 NineData 作为示例？

这里主要是借它来说明一条比较完整的异构复制链路：从数据源接入，到结构、全量、增量复制，再到延迟观察、数据比对和任务告警。文章重点想表达的是实施路径本身，而不是单独讨论某一个产品。

写在最后

Oracle 到 MySQL、Oracle 到 PostgreSQL 这类项目，难点通常不只是把数据迁到目标端，而是如何让结构初始化、全量复制、增量追平、延迟观察和切换前核验形成一条连续链路。对于需要持续运行一段时间的异构同步任务来说，把这些动作拆散处理，后续维护成本往往会逐渐上升。本文用 NineData 作为示例，重点想说明的并不是某个产品本身，而是这类异构复制项目更适合按“复制、观察、核验、切换”几个阶段来理解和实施。