FAQ

常见问题

关于 SyncTool 你最关心的 12 个问题,包括我们不擅长的地方

SyncTool 需要什么外部依赖?

零外部依赖。 不需要 Kafka、ZooKeeper、Redis、消息队列、容器编排 —— 甚至不需要数据库。工具自身使用 H2 内嵌数据库存储元数据,一个 jar 即可启动。前端资源全部在仓库内,运行时不发起任何外部请求,内网离线完全可用。

支持哪些数据库?

MySQL、MariaDB、Oracle、SQL Server、DB2、PostgreSQL、OpenGauss、达梦 (DM)人大金仓 (KingBase)南大通用 (GBase)神通 (Oscar)、H2,以及自定义数据库(提供 JDBC URL、驱动类名与驱动 jar 路径,运行时动态加载)。

内置驱动仅 MySQL / PostgreSQL / H2;其余数据库需在连接配置中填写驱动 jar 路径,工具会用独立 URLClassLoader 加载。发行包不必捆绑商业驱动,也不会因驱动版本冲突污染应用类加载器。

能和 Debezium、Canal 这些工具比吗?

适用场景不同。SyncTool 定位在中小规模、信创迁移、内网离线场景 —— 一个 jar 启动,浏览器点几下就能跑。Debezium/Canal 在毫秒级延迟和大规模流式处理上更强,但需要一套完整的基础设施。

如果同步需求的规模配不上一套流式基础设施的运维成本,SyncTool 是决定性的选择。

支持结构同步吗?

支持。结构同步是 SyncTool 的一等公民 —— 自动读取源库元数据,按目标库方言创建表、索引、视图、存储过程,并在源库 DDL 变更后把差异传播过去。

跨异构库迁移里,建表和类型映射的工作量往往比搬数据本身更大。这是 SyncTool 和大多数 CDC 工具的一个关键差异。

会不会丢数据?

不会。采用了三种机制保证数据不丢:

① 先提交后推进: 先提交目标库数据,再持久化游标。若两者之间崩溃,下次重放同一窗口。
② 幂等写入: 每一行通过基于主键的 upsert 写入,重复执行收敛到同一状态。
③ 安全回退: 持久化水位线时回退 safety-lag-ms(默认 1 秒),避免晚提交的事务被跳过。

进程重启后从上次游标继续,停机期间的变更会被补齐。

同步需要修改源数据库吗?

不需要。 SyncTool 只需要一个只读账号,通过查询游标列做增量,源库结构和配置一动不动。不需要建触发器、不需要开 binlog、不需要申请复制权限。

在很多生产库上,数据库变更是一次要走审批流程的操作。这个「零侵入」特性让 SyncTool 在信创迁移场景里尤其有优势。

怎么处理修改同步不过去的问题?

游标列必须是「改一行它就会变大」的列,否则修改对同步不可见。工具会自动识别 update_timeupdated_at 等命名约定的列作为 TIMESTAMP 策略游标。

如果表没有符合条件的列,可在项目详情页手动指定游标列。已漏掉的修改可通过「重置进度」触发全量加载来补全。

长期方案: 给源表添加一个真正会变的最后修改时间列,如 MySQL 的 ALTER TABLE t ADD COLUMN update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

密码和密钥怎么管理?

登录密码使用 BCrypt 单向哈希存储,无法逆向还原。数据库连接密码和 AI 供应商密钥使用 AES-256 加密后入库(带 enc: 前缀标记)。

crypto-passwordcrypto-salt 生产环境必须修改,修改后已存储的旧密码将无法解密,需在界面上重新填写。

忘记管理员密码:删除 app_user 表对应行,重启后自动种回初始密码。

同步延迟有多大?能做到毫秒级吗?

轮询方案的延迟下限就是轮询间隔,默认 2 秒,可通过 sync.poll-interval 调整,也可用 Cron 表达式精确编排。

如果你需要毫秒级延迟或严格的变更顺序,应该用 Debezium / Flink CDC —— 它们解析 binlog / WAL,是日志级的捕获。这一点我们不打算含糊:SyncTool 换取的是「零基础设施」,代价就是延迟。

能同步物理删除吗?

能,但有条件。无源库审计表时,删除检测需要比对双方主键全集,开销随表增大而增大,因此仅对行数低于 full-compare-max-rows(默认 20000)的表启用。

删除同样是基于主键的条件删除,重复执行无副作用。如果你的大表需要同步删除,建议在源库维护一个软删除标记列(配合 update_time 游标),比全量主键比对可靠得多。

没有主键的表能同步吗?

能同步,但无法保证幂等 —— 没有主键就无法识别既有行,重放时可能产生重复行。工具会明确告警。

由于「先提交数据、再推进游标」的设计决定了同一行可能被投递两次(崩溃后重放窗口),幂等性是数据正确的前提。所以强烈建议为表添加主键。

AI 辅助转换是什么?会把我的数据发出去吗?

存储过程里的不兼容语法,靠文本替换只能走到一定程度。AI 辅助转换让模型起草一份候选,由你审阅后落库。边界是硬的:

① AI 只产出候选,永远不直接参与同步StructureSyncService 不调用任何 AI 代码
② 候选需人工确认后才写入项目的 ddlOverrides
③ 没有启用任何供应商时,工具不产生任何外部请求
④ 设置 sync.ai.enabled=false 可彻底移除该功能

但请注意:转换时会带上存储过程的源码发给你配置的端点,其中往往包含业务规则甚至表结构全貌。内网或有合规要求的部署,请优先接入本地/自建推理端点,并自行确认这些代码允许外发。

另外,没有任何工具能保证转换后「效果与原来完全一样」,AI 也不能。存储过程的差异往往不在语法而在语义。所以这里的定位是起草,不是保证