开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第22天，，点击查看活动详情
数据库同步有3大难题： 1是如何保障目标和源数据一致性； 2是异构数据库如何做数据类型转换，导致数据同步失败的原因常常是因为数据类型不一样； 3是在数据越实时越有价值的背景下，同步过程中能否做到实时同步。
一、几种主流的数据库同步方式
方式一：基于无侵入的日志模式(如Oracle redo、Mysql binlog） 基于日志的采集方式无需在源库端部署任务代理程序(Agent)及建任何表，对源数据库无侵入和影响压力；
方式二：基于时间戳 同步过程通过特定属性（如时间戳、自增序列）来识别新插入的数据，该方式实现最简单，但无法记录删除和更新，也不具备实时的能力；
方式三：基于触发器 基于数据库的触发器机制，当执行DML相关语句时，执行动作来捕获数据，该方式会降低系统能，因此大多数场景下，生产系统不允许添加触发器。
方式四：基于快照 基于快照的方式，可以通过比较源表和快照表来获得数据变化，但需要消耗大量存储空间和计算资源。
方式五：基于离线批处理 通过jdbc查询来批量获取数据，会进行数据表的大范围扫描和数据提取，会对数据库产生大量开销。
本文主要探讨无侵入的CDC模式，并以运用这种模式的数据库同步云工具 Tapdata Cloud 举例。
二、架构及工作原理
Tapdata Cloud包含两部分：
- Tapdata Cloud Manager，TCM是Tapdata Cloud的管理端，负责agent实例的安装，同步任务的配置、分发、任务状态监测。
- Tapdata agent，是Tapdata Cloud数据同步服务的执行实例，负责从TCM获取任务信息，通过流式技术从源系统获取数据、处理转换数据并发送到目标系统，并在任务执行过程中监测并上报任务状态至TCM。
有朋友可能会担心这个云平台会不会把我要同步的数据泄露出去？
从Tapdata Cloud 工作原理上可以看出：
- 同步实例节点单向连接管控端运行服务。 Tapdata agent实例节点对外不主动暴露网络信息，只会连接 TCM管理端服务，获取任务信息、上报状态信息。
- 用户部署的Tapdata agent实例节点和 TCM 通信链路采用 HTTPS 协议。
- 自建模式下，所有数据流转均发生在受用户管理的服务器和网络环境。 可见，数据同步过程中数据泄露的问题大可不必担忧。
三、全量同步和实时增量同步机制
Tapdata Cloud 这款云同步工具支持全量同步和实时增量同步，实现的过程如下图所示：
四、源和目标
据 Tapdata Cloud 最新版本，目前支持了： 数据库| 版本 |作为源 |作为目标| 是否可用 -------- | ----- | ----- | ----- | ----- | ----- mysql | 5.x，8.x | 支持 | 支持 | 是 oracle | 9i, 10g, 11g, 12c | 支持 | 支持 | 是 sqlsever | 2005, 2008, 2012, 2014, 2016, 2017 | 支持 | 支持 | 是 mongodb | 3.2, 3.4, 3.6, 4.0, 4.2 | 支持 | 支持 | 是 PostgreSQL | 9.x, 10.x，11.x，12.x，13.x | 支持 | 支持 | 是 Elastic | 5.x, 6.x, 7.x | 暂不支持 | 支持 | 是 达梦数据库 | 7,8 | 支持 | 支持 | 是 Kafka | 2.3.x及以上 | 暂不支持 | 支持 | 是 Redis | 2.x, 3.x, 4.x | 暂不支持 | 支持 | 即将上线 DB2 | 9.7 LUW版本 | 支持 | 支持 | 即将上线 Sybase | Sybase ASE 15.7 及以上 | 支持 | 支持 | 即将上线 Gbase | | 支持 | 支持 | 即将上线
下一篇将演示如何使用Tapdata同步数据库
