将 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;
错误处理:异构同步涉及 Java 端(如网络断开、Schema 不匹配)和 C 端(如主键冲突、表不存在、权限不足)。SynchDB 会将两边的错误信息统一汇总在 synchdb_state_view 中,帮助 DBA 快速定位并解决问题。
六、总结与展望
SynchDB v1.3 已于 2025 年 11 月 25 日正式发布。目前它支持 MySQL、SQL Server、Oracle 和 OpenLog Replicator;支持全量快照、CDC 实时捕获;支持 DML/DDL 同步;并提供 Prometheus & Grafana 监控集成。
在当今 AI 爆发的时代,大家都渴望使用 PostgreSQL 强大的生态。而海量的数据往往还沉睡在 MySQL 或 Oracle 中。团队希望通过 SynchDB,让数据流向 PostgreSQL 的过程变得高效、丝滑且低成本。
SynchDB 是完全开源的,项目地址在: https://github.com/Hornetlabs/synchdb 。非常欢迎感兴趣的开发者、DBA 提交 Issue 或 PR,共同参与建设,让这个社区工具变得更完善、更强大。如果对数据库技术有更多兴趣,也可以到 云栈社区 与更多同行交流探讨。