从异构数据库到 PostgreSQL 的逻辑复制：开源扩展 SynchDB 的设计与实践

关注

原创最新推荐文章于 2026-11-14 14:38:32 发布 361 阅读 AI 写同款· GEO 优化 ›

SpringBoot+Vue+MySQL 高校学科竞赛平台完整可运行版（源码+文档）本项目基于SpringBoot+Vue+MySQL构建高校学科竞赛管理平台，覆盖学生、教师、领队教师、管理员四大角色，实现竞赛发布、报名、刷题、评分、公示等全流程闭环管理。系统架构清晰，技术主流，配套完整源码、数据库脚本、万字论文、开题报告、答辩PPT及部署文档，支持一键运行，适用于毕业设计、课程设计及院系二次开发，真正实现“开箱即用”。阅读详情

导读：将 MySQL、SQL Server、Oracle 等异构数据库的数据实时同步到 PostgreSQL，通常需要依赖 Kafka 等复杂的中间件架构。在 HOW 2026 分享中，PostgreSQL 社区 Significant Contributor、来自 Hornetlabs 的技术专家 Cary Huang 详细解析了一款专为 PostgreSQL 打造的开源扩展——SynchDB。它通过内嵌引擎和巧妙的架构设计，让异构数据库的实时逻辑复制变得前所未有的简单。

一、为什么需要异构数据库复制？

在当今的 IT 架构中，数据往往散落在不同的数据库系统中。业界常需要将 MySQL、SQL Server 或 Oracle 中的数据抽取并同步到 PostgreSQL 中，用于数据分析、报表生成或数据仓库建设。

为什么选择 PostgreSQL 作为目标端？

成本低廉：强大且开源，是替代传统商业数据库的理想选择。
生态丰富：原生支持 JSONB、GIS 地理空间、向量和全文搜索等，且拥有丰富的插件体系。
云原生便携性：在 AWS、Azure、GCP 及本地环境均可无缝运行，避免数据被单一厂商锁定。

异构复制为何困难？
跨数据库复制最大的痛点在于差异：数据格式、语义、工具、协议各不相同。其次，实时变更数据捕获（CDC）涉及极高的复杂度，如数据漂移、错误处理、Schema 变化（如加列、改主键）、事务边界和一致性等，稍有差错就会导致数据不一致。

二、现有方案的局限

目前，业界主流的异构数据同步方案主要有两种：

1. Debezium + Kafka 架构
它的优势在于支持广泛的数据库、实时 CDC 和借助 Kafka 实现的容错性。但缺点同样明显：架构极其复杂（需要部署 Kafka、Kafka Connect、Zookeeper 等），资源消耗巨大；数据需要经过“源端 -> Kafka Topic -> Kafka Sink -> PostgreSQL”，多阶段流转带来较高的延迟；且 Schema 管理和数据转换能力受限。

2. Oracle GoldenGate
这是一款商业软件，功能非常强大，但高昂的 License 费用、陡峭的学习曲线以及对非 Oracle 数据库兼容性的局限，让许多企业望而却步。

那么，有没有一款专为 PostgreSQL 量身定制、轻量且灵活的选项呢？

三、隆重推出 SynchDB

SynchDB 是一款开源的 PostgreSQL 扩展，它允许 PostgreSQL 直接从 MySQL、SQL Server、Oracle 和 OpenLog Replicator 等异构数据库进行逻辑数据复制。所有的操作均在 PostgreSQL 内部控制和管理。

它的核心优势可以概括为：

极简安装：仅需 PostgreSQL 和 Java 运行环境（JRE 17+），执行 CREATE EXTENSION synchdb CASCADE; 即可完成安装。
易于使用：通过 SQL 函数即可完成连接器（Connector）的创建、启动和状态监控。
灵活的数据转换：不仅支持表名、列名、数据类型的映射，还能直接利用 PostgreSQL 的 SQL 函数进行表达式级别的数据清洗。
多连接器架构：支持同时连接多个异构数据源。

1. 核心架构：C 与 Java 的无缝融合

因为要复用 Debezium 强大的 CDC 采集能力，而 Debezium 是基于 Java 编写的，SynchDB 的架构巧妙地将两者结合了起来：

PostgreSQL 后台工作进程（C 语言编写）：负责与 PostgreSQL 内核交互，处理 DDL/DML，以及执行数据转换规则。
JVM（Java 虚拟机）：SynchDB 并没有将 JVM 作为一个独立的进程运行，而是通过 JNI（Java Native Interface） 将 JVM 内嵌在 PostgreSQL 的后台工作进程中。

数据流向：外部数据源的变更事件由 Debezium Connector 采集，以 JSON 格式通过 JNI 传递给 SynchDB，经过解析、格式化、转换后，通过 Executor API 或 SPI 写入 PostgreSQL。

2. JNI 的代价与性能优化

通过 JNI 调用 Java 资源是有性能开销的。根据演讲中提供的测试数据：如果在 JNI 中调用一个简单的算术方法，调用 10 亿次时，耗时可能是原生 Java 的 15000 到 20000 倍。

如何解决？
SynchDB 采用了**批量处理（Batching）**的策略。把繁重的工作卸载到本地代码（C），减少 JNI 的调用频率。在 Debezium 引擎中维护一个 Batch Queue，将采集到的变更事件累积成批，再统一传递给 SynchDB 插件。批次越大，JNI 调用越少，性能越好。

四、关键技术细节解析

1. 初始快照（Initial Snapshot / Table Sync）

在开启实时 CDC 之前，必须先对现有数据进行全量拷贝。SynchDB 支持两种模式：

基于 Debezium 的快照：流程是建立连接 -> 确定捕获表 -> 获取全局读锁（防止数据写入） -> 开启 Repeatable Read 事务 -> 读取当前 binlog/SCN/LSN 位置 -> 记录 Schema -> 释放锁 -> 迁移数据 -> 提交事务并记录 Offset。
基于 FDW 的快照（推荐）：Debezium 的快照在表数量巨大（如数千张表）时非常慢。SynchDB 创新性地引入了 FDW（外部数据包装器），利用 mysql_fdw、oracle_fdw 等原生高速接口进行初始全量同步。通过 AS OF SCN 等技术确保读取特定范围的数据，极大提升了海量表的迁移速度。

2. 灵活的数据转换规则

SynchDB 不仅仅能映射数据类型（如 MySQL 的 Varchar 转为 PG 的 character varying，Enum 转为 text），它的杀手锏是表达式转换。

因为 SynchDB 是运行在 PG 内部的，用户可以直接调用 PG 的 SQL 函数对流入的数据进行处理。例如：

配置规则 %d + 1000：数据写入时自动给数值加上 1000。
配置规则 SELECT pg_compress(%d)：在数据落库前进行压缩。
使用 ST_GeomFromWKB 处理地理空间数据。

这是将同步工具作为外部中间件（Middleware）极难做到的优势。

3. 大事务处理（Infinispan）

如果源端产生了一个超大事务（涉及几十万甚至上百万行更新），数据在 COMMIT 之前都必须缓存在内存中。这极易撑爆 JVM 的堆内存导致 OOM。

为此，SynchDB 集成了 Infinispan，它可以将大事务的数据溢出到堆外内存（Off-heap），甚至在必要时写入磁盘。直到收到 COMMIT，再将数据安全地应用到 PostgreSQL。

4. 并发控制：多进程与多 JVM

PostgreSQL 是多进程架构，而 Java 是单进程多线程环境。在 PG 中，无法通过多线程直接并发写入数据，这会导致事务冲突和锁竞争。

其解决方案是：采用多进程实现安全的并发。
系统可以启动多个 SynchDB Worker 进程，每个进程内运行独立的 JVM。例如：

Worker 1 负责同步表 1, 2, 3
Worker 2 负责同步表 4, 5, 6
它们相互独立，分别向 PostgreSQL 发起事务。利用 PostgreSQL 本身的 MVCC 机制处理隔离级别和锁保护，从而实现性能的线性扩展（代价是消耗更多的 JVM 内存）。

五、快速上手与监控

SynchDB 的使用非常简单，全程通过 SQL 操作：

-- 1. 创建连接信息（填写远端数据库信息、要同步的表等）
SELECT synchdb_add_conninfo('mysqlconn', '127.0.0.1', 3306, 'mysqluser', 'mysqlpwd', 'inventory', 'postgres', 'inventory.orders', 'mysql');

-- 2. 启动引擎
SELECT synchdb_start_engine_bgw('mysqlconn');

-- 3. 查看状态和统计信息
SELECT * FROM synchdb_state_view;
SELECT * FROM synchdb_stats_view;