Jync 捷同 · 异构数据库实时同步工具

不要 Kafka，不要 Flink，不要 ZooKeeper，不写一行作业代码。浏览器点几下，Oracle 与 PostgreSQL、MySQL 与达梦之间就能持续保持结构与数据一致——同步之前还能先排练一遍，数据库里的变化也能实时投影进 Redis。

一、为什么又造一个同步工具？

企业里的数据库从来不是一种。老系统跑在 Oracle、SQL Server 上，新业务选 MySQL、PostgreSQL，信创改造还要迁到达梦、金仓、openGauss、崖山。数据要在这些库之间流动，现有方案却总差一步：

• Debezium、Flink CDC 能力很强，但要先搭 Kafka / Flink / ZooKeeper，写消费作业，还要源库开 binlog、给复制权限；
• DataX、Kettle、Navicat 数据传输 擅长「搬一次」，不负责长期增量、结构同步与断点续传；
• 商业同步工具 按节点授权，采购周期和成本都不适合部门级、项目级的同步需求。

Jync 想填的就是这个空档：把任意两种异构数据库之间的持续同步，做成分钟级部署、零外部依赖、只读账号就能跑的开箱即用应用。

到了 v1.12.0，它要回答的问题又往前走了一步：同步之前，能不能先知道会建什么表、改哪些列？同步之后，行数对得上，内容真的对得上吗？出了问题，能不能一键把现场带走，而不是让实施人员在客户机房里翻日志？

到了 v1.13.0，问题继续往前：数据库里的热数据，能不能在同步落库的同时直接投影进 Redis，让业务读缓存而不是反复查库？客户还在用 MySQL 5.7，工具能不能自己识别版本、不再把日志刷满？

二、Jync 是什么

Jync（读作 sync，J 代表 Java；中文名「捷同」——敏捷同步，两库皆同）是一个在异构数据库之间实时同步结构与数据的 Web 应用。单个 jar 启动，内置 34 种数据库类型（另支持自定义 JDBC 类型），在浏览器里建两条连接、选好表，就能建立持续同步链路。

搜索与文档型数据另有三条不走 JDBC 的专属迁移链路：Elasticsearch / OpenSearch → Easysearch、MongoDB → MongoDB、MongoDB → KingbaseES。它们用独立的连接模型做整库复制，与实时同步、ETL 互不影响。

缓存侧同样不走 JDBC：Redis 只作为实时同步的目标，由日志 CDC 把行级变化投影成缓存键值。它不是新的数据库类型，连接、预检与重建都按缓存语义单独处理。

源库只需要一个只读账号：不装 Agent、不建触发器；轮询模式不需要开 binlog，需要秒级延迟时再切换日志 CDC（此时按源库类型另需 binlog / 归档日志 / 复制权限）。

它同时提供七类能力：

• 实时同步：结构 + 数据一起同步，全量初始化后持续追增量；
• 日志 CDC：六类源库可切到秒级日志回放；
• 缓存投影：日志 CDC 的行级变化实时写入 Redis，支持 JSON / HASH 两种值形态；
• ETL：按客户 SQL 取数写入目标表，支持批次、断点续跑与多语句脚本；
• 专属迁移：搜索索引与 MongoDB 集合的整库复制，独立于 JDBC 体系；
• 可验证性：同步前检查、内容级校验、一键诊断包与真实库验证矩阵；
• 告警与可观测：故障主动推送，看板、变更日志、性能曲线与 Prometheus 指标一屏掌握。

三、核心能力

1. 结构也同步，不只是搬数据

按目标库方言自动创建表、索引、视图与存储过程；源库发生 DDL 变更后，差异会自动传播到目标端。迁移一个系统时，不用再拿两份建表脚本手工对齐。

转换不是简单的字符串替换：DECODE / NVL2 改写为 CASE、CONVERT 转 CAST、分页语法与 WITH ROLLUP 按目标方言重写、DECIMAL 自增列按目标规则提升为整数类型。跨方言族的过程化正文，以及无法保证等价的写法，会被明确阻断并提示用 DDL 覆盖，而不是生成一段「能跑但结果不对」的 SQL。

2. 零侵入增量：每轮只发一条索引查询

默认 2 秒轮询，也可用 Cron 编排。系统自动识别游标列：TIMESTAMP 识别新增与更新、ROW_SCN 识别 Oracle 行级变更、IDENTITY 只识别新增；有主键的小表可启用整表比对，大表可改用按主键分页的分块比对。

可靠性上做了三件事：闭区间增量窗口避免边界丢行；批次提交后才推进游标，崩溃重放不会跳过数据；按主键幂等 upsert，重复执行也收敛到同一状态。任务重启后从游标继续，停机期间的变更自动补齐。

3. 全量加载：分块并行，大表可续跑

首次全量不是「一条 SELECT * 灌进去」：有主键的表按 keyset 切成互不相交的区间，单表内并行加载，结果集流式读取，逐块提交并写检查点，堆内存不随表大小增长。容器单机、50 万行 Oracle 表的全量实测约 21.6 万行/秒。

v1.12.0 修复了千万级大表在源表持续增长时反复重试、无法完成首轮全量的问题：重试不再按当前主键范围重新切分，而是沿已记录的区间布局续跑；新增行只在尾部追加，中间的空隙补区间，改并行度也不触发整表重载。只有布局不完整或前后矛盾时，才丢弃旧检查点从头加载。

v1.13.0 又处理了一个很现实的兼容问题：MySQL 5.7 没有窗口函数。并行全量原本会用窗口函数按主键采样切分，在 5.7 上会直接语法报错，只能退回顺序分块——数据不丢，但每张表、每次全量都打一条错误日志，实施人员看到的是一屏红色。现在构建同步上下文时会从服务器元数据读取主版本，按连接分别下发给源与目标方言：5.7（以及 MariaDB 10.2 之前）直接走顺序分块，每个项目只提示一次；两端版本不同也能各用各的规则。版本读不到时仍保持「先尝试、被拒再回退」，不影响 Doris、TiDB 这类 MySQL 协议产品。

4. 六类日志 CDC：秒级延迟

需要更低延迟时，可以把任务切到日志 CDC：

• MySQL binlog；
• Oracle LogMiner；
• 达梦 LogMiner；
• PostgreSQL 系逻辑解码（含 openGauss 等国产内核）；
• SQL Server CDC；
• 崖山 YStream。

统一流程是「记录位点 → 分块全量基线 → 长驻线程连续回放」，看到的就是源库真实的 INSERT / UPDATE / DELETE。同一任务的 CDC 流用数据库租约互斥，持锁节点宕机后 ≤ 60 秒由其他节点接管续传。

CDC 的前提条件由探测逐项检查：MySQL 的 binlog_format=ROW 与 binlog_row_image=FULL、Oracle 的 ARCHIVELOG 与补充日志、达梦的 RLOG_APPEND_LOGIC=2、PostgreSQL 系的 wal_level=logical、SQL Server 的库级 CDC、崖山的逐表补充日志。不满足会直接告诉你缺哪一项。

5. Redis 缓存投影：让缓存跟着数据库一起变

缓存最难的不是把数据写进去，而是数据库变了，缓存怎么跟着变。常见做法是业务代码里双写，或者定时全量刷新；前者容易漏，后者永远慢一拍。v1.13.0 把这件事收进了同步链路：日志 CDC 项目可以直接把 Redis 选为目标，每一行 INSERT / UPDATE / DELETE 都按行投影成缓存键值。

它不是新的一种数据库类型，不会出现在源端下拉、ETL 引擎列表或数据库能力矩阵里，只出现在项目页的「目标类型」。连接也是独立维护的：host、port、database、ACL 用户名、密码、TLS、Cluster 模式各自配置，密码只存加密字段，测试连接执行 PING。

投影规则很直接：

• 键为 <前缀><表名>:<主键…>，前缀默认 jync:<项目ID>:，同一 Redis 上多个项目互不干扰；
• 值可选 JSON（默认，整行镜像，DECIMAL 写成字符串避免精度丢失）或 HASH（列名作 field，NULL 列不写字段）；
• 可设置 ttlSeconds、排除列与单值上限，超限的行按事务汇总成一条 WARN，不刷屏也不停机。

可靠性沿用 CDC 的同一套纪律：先做分块基线（只投影有主键的表），完成后再流式回放；目标写入失败时位点不推进、消费者退避重连，恢复后从原位点重放。SET / HSET / DEL 本身幂等，重放最终收敛。每个 CDC 事务的命令先缓冲，提交时走一次管道并逐条检查回复，不使用 MULTI/EXEC，避免集群同槽限制。

项目详情页提供「重建」：可以先按本项目前缀清扫（SCAN + UNLINK，只动自己的前缀，绝不 KEYS / FLUSHDB / FLUSHALL）再重新基线。同步前检查也会切到 Redis 专用项——连通性、TLS、集群槽与 databaseIndex、maxmemory-policy、键前缀冲突、选表主键与基线状态，全程只读。

边界要说清楚：Redis 只支持日志 CDC 源，结构 / 索引 / 视图 / 存储过程同步强制关闭；无主键表不投影；不支持 Sentinel，集群模式不做 hash tag。缓存被驱逐或 Redis 重启丢数据，Jync 感知不到——读不到就回源，或者执行一次重建。它解决的是「缓存跟着库走」，不是「缓存永不丢」。

6. ETL 与批次：同源同目标共享一对连接

除了实时同步，Jync 还支持按客户取数 SQL 复制结果行，覆盖追加、覆盖、范围覆盖三种写入方式，支持多语句脚本与断点续跑。

ETL 批次把同源同目标的一组表放进一个批次，共享一条调度和一对源/目标连接，组内按顺序执行；单个成员失败不中断后续成员。批次创建后连接锁定，成员不再单独调度，也可以从表清单批量勾选生成默认 select * 的任务，之后再逐个改写 SQL。

ETL 侧内置 SAP HANA、Doris、ClickHouse、Hive、Impala、Elasticsearch、MongoDB 七种分析型引擎；MongoDB 还提供原生驱动预置，任何 mongod 都能直连，不需要 SQL 或额外 jar。

7. 专属迁移：搜索与文档型数据不走 JDBC

有些数据源不是关系库，硬塞进 JDBC 模型只会处处别扭。v1.11.0 起，Jync 提供三条独立的专属迁移链路：

• Elasticsearch / OpenSearch → Easysearch：自动发现索引，复制 settings、mappings、别名，按 _id / _routing 批量写入，刷新后做行数与抽样校验；
• MongoDB → MongoDB：复制集合选项与索引，文档原样写入并保留 _id，支持覆盖、追加、冲突即失败三种方式；
• MongoDB → KingbaseES：从有界样本推断 BSON → 列类型，自动建表，_id 可作主键并开启幂等 upsert；嵌套文档与数组写成 TEXT 的 relaxed Extended JSON。

三条链路都有预检：源端可达、目标冲突、类型不兼容、MongoDB 同库自复制等问题在运行前给出明确错误。任务可手动或 cron 运行，支持取消、超时与最近 50 次运行历史。

8. 同步前检查：把下一轮先排练一遍

v1.12.0 新增的同步前检查是只读的：不执行 DDL、不写快照、不推进游标，只在项目详情页点一下，就告诉你下一轮同步会发生什么。

检查项按固定顺序返回：

• 源 / 目标连通性；
• 待执行的 CREATE / ALTER / DROP，以及表名映射冲突；
• 目标表缺失、缺列、类型不兼容（结构同步打开时降为警告，关闭时报错）；
• 轮询游标列是否缺失、有没有索引、表有没有主键；
• 日志 CDC 的探测项是否通过；
• binlog CDC 持久化的表布局签名是否漂移。

结果按 ERROR / WARN / OK / SKIP 分组。最典型的一类问题在停机期间：源表跑过 DDL，CDC 的列布局已经变了，继续回放就会错位——预检会直接报错并提示重建基线。

预检不能替代一次真实同步，但它能把「启动之后才发现建表失败」提前到点击按钮的那一秒。

9. 内容级校验：行数对得上，内容呢？

传统的行数审计只能发现「目标比源少」，发现不了行数相同但值不同：更新丢失、字段截断、字符集或类型转换出错，都会让两份数据悄悄分叉。

v1.12.0 在增量同步成功后增加内容级校验：按主键分桶抽样，取源与目标同一批 key 的投影列逐值比对。比对前先做列清洗，数字、时间、布尔统一规范化；LOB、JSON、XML、几何等无法可靠比较的列自动排除。差异只写变更记录并发 DATA_DRIFT 告警，不自动修复——目标端的外部触发器、手工修订或转换规则也会表现为差异，工具不该替人做决定。

默认 15 分钟一次、每表 50 行、单表 200 万行上限、每个项目每周期 1 张表、单次 60 秒超时，全部可用 sync.content-audit-* 调整；设 sync.content-audit-interval-ms=0 即关闭。管理员也可以对单表手工触发「校验内容」。

10. 一键诊断包与真实库验证矩阵

出问题时最耗时的往往不是修，而是收集现场。v1.12.0 在设置页给管理员提供「一键诊断包」：一个 zip，包含版本、脱敏后的配置、连接、项目进度、CDC 位点、近期变更与日志尾部，每个条目在 manifest.json 里附 SHA-256。

白名单是第一道防线：密码、密钥、enc: 密文、带凭据的连接串、游标原值、data/ 目录与原始 application.yml 都不入包；条目内容再经一次脱敏，替换密码 / token 类赋值、Bearer、URL 账号信息与私钥块。整个包有 10 MB 上限，超限直接报错而不是把 JVM 拖进 OOM。

同版本还补了 docs/verification-matrix.md：逐产品写明测试版本 / 镜像、驱动、源/目标角色、已验证策略、验证级别（自动化容器 / 环境变量门控 / 手工）与最后验证日期。没跑过的产品就写「未验证」，不因为驱动内置或单元测试通过就写成已验证。

11. 告警与可观测：问题主动找你

同步失败、轮询卡死、项目未运行、CDC 停摆、数据漂移、连接健康、PG slot 积压等七类故障，可推送到通用 JSON、钉钉、企业微信、飞书或自定义 Webhook；支持冷却时间与恢复通知，地址加密存储。

页面侧提供看板、变更日志、审计日志、系统日志、每表吞吐、性能曲线与 CDC 状态面板；行数不一致时可按需发起行数核对，内容不一致时可触发单表内容校验。可选开启 Prometheus 指标端点，接入既有监控体系。登录支持本地账号与三种统一认证（账号密码、网关头、票据），同一时刻只生效一种。

四、技术架构与工程取舍

• Java 17 + Spring Boot 2.7 单体架构，Thymeleaf 服务端渲染 + 原生 JS，无前端框架、无构建步骤；
• Quartz 调度 + 数据库租约：调度、JVM 锁、数据库锁行三层保护，多实例部署时同一任务只在一个节点执行；
• H2 内嵌元数据库：连接、项目、游标、锁、变更日志全部自管理，不用另装数据库；替换 jar 重启即可，表结构由启动时自动补齐（v1.13.0 新增的 redis_target 表就是这样建出来的）；
• 34 种预设类型、25 种驱动随包内置；GBase、神通 Oscar、GaussDB、SAP HANA、ClickHouse 等厂商提供的构件不可再分发，需自备 jar，运行时动态加载并做 ClassLoader 隔离；自定义类型填 JDBC URL、驱动类名与 jar 路径即可；
• 连接池按配置缓存：每条连接配置一个池，配置指纹变化时透明重建、不留旧凭据；池满时同步周期排队等待而不是直接失败；
• 内网离线可用：前端资源全部内置，默认运行时零外部请求；AI 辅助与 Webhook 都是可选项；
• 测试兜底：4972 项自动化测试（4971 通过，1 个仅限 Linux 的密钥文件权限用例在 macOS 上跳过），含真实数据库契约测试与端到端断言。

真实库验证分三级：MariaDB 11.4、ClickHouse 24.8、PostgreSQL 16、MySQL 8.0、Oracle 23 Free、SQL Server 2022、openGauss 5.0.0 跑自动化容器；Doris、KingbaseES、YashanDB 用环境变量门控；SAP HANA、Elasticsearch SQL 保留手工步骤。bash scripts/run-verification-matrix.sh 会把跑过的、跳过的和原因逐条打印出来。

性能上，容器单机、50 万行 Oracle 表的全量加载实测约 21.6 万行/秒；日志 CDC 端到端延迟为秒级。对于几十张表、百万到千万行的常见信创迁移规模，延迟与吞吐处于和 Flink CDC 同一量级——区别在于部署面只有一个 jar。

五、和同类方案比

一句话总结：当同步规模还撑不起一套流式基础设施时，Jync 是更合适的答案。

六、五步跑起来

# 从 Releases 下载成品 jync.jar，或从源码构建
java -jar jync.jar

浏览器打开 http://localhost:8080，默认账号 admin / 123456（管理员）或 view / 123456（访客），首次登录必须改密。接下来的流程只有五步：

1. 建源库连接；
2. 建目标库连接；
3. 新建项目，选择源端与目标端；
4. 勾选要同步的表 / 视图 / 存储过程；
5. 点「启动同步」。

建议在启动前先点一次「同步前检查」，确认没有待处理的建表、缺列或 CDC 布局漂移；同步跑起来之后，在项目详情页看每表吞吐、变更日志与内容校验结果。

生产环境建议用 systemd 托管，并修改 application.yml 中的 sync.crypto-password 与 crypto-salt。升级时备份 ./data 与 application.yml，替换 jync.jar 重启即可。

七、适用边界

适合：

• 几十张表、百万到千万行，部门级 / 项目级的持续同步；
• 内网、离线、信创环境，要求私有化部署；
• 需要在 Oracle / SQL Server / MySQL / PostgreSQL 与国产库之间迁移并持续保持一致；
• 需要把 ES / OpenSearch 索引或 MongoDB 集合整体搬到另一套存储；
• 需要让 Redis 里的热数据跟着数据库实时变化，又不想在业务代码里维护双写；
• 希望 DDL 变更、断点续跑、失败告警、同步前检查与内容校验都由工具负责，而不是自己写作业。

不适合：

• 毫秒级延迟、单表数亿行的一次性初始化；
• 复杂 ETL 调度与多主双向复制。

以上场景更适合交给对应的专业流式或数据集成产品。

八、开源与获取

Jync 基于 MIT 协议开源，商业与非商业用途均可。

• GitHub：https://github.com/vfaner/jync/releases/latest
• Gitee：https://gitee.com/super_rgh/jync/releases/latest
• GitCode：https://gitcode.com/vfaner/jync/releases/latest
• 14 分钟演示视频：https://www.bilibili.com/video/BV1iHYJ6vEEd

如果你也受够了「为同步两张库搭一套 Kafka」，或者「每次改表结构手动对齐两边」，欢迎试试 Jync——顺手点个 Star、提个 Issue 就更好了。