TapData实际体验

昨天博主介绍了TapData数据同步解决方案,但是仅仅做了测试,今天我们来实战一下,看看实际表现如何。

--应用场景

目前公司有两个商城系统,新旧系统均在使用。用户登录整合在新系统。

在旧系统注册用户后,需要等次日零点才可以在新系统登录。

因为是通过job在零点进行数据的同步工作,但是弊端也很明显,采用的是查询同步,所以会占用系统CPU以及磁盘大量的资源,严重时会影响正常业务;同时由于同步不及时,对用户体验有很大的影响。

--系统数据简介

以下数据为截取生产环境数据,并做脱敏处理。

1.表数据

本次同步数据为该系统用户表,数据量为44万

数据类型如下

 

2.数据库主机配置

 配置为4核24G内存,目前系统占用率为0,处于闲置状态。系统为ubuntu 20.04.2

3.Agent主机配置

博主使用的为昨日新建的实例。

配置为4核4G内存。当前CPU使用为5%,内存为54%

--同步前准备

1. 连接测试

输入我们的数据库信息,然后进行检测,检测结果如下(不清楚如何操作的同学可以参考上一篇文章)。

 从图中我们可以看到需要打开binlog日志,并且是row级别;同时应赋予该数据库账号cdc同步权限。

这里为大家介绍一种开启binlog的方法

1.1 开启binlog

binlog是二进制日志文件,用于记录mysql的数据变更,数据在恢复的时候binlog日志能起到很大的作用

1、 登录mysql之后使用下面的命令查看是否开启binlog

show variables like 'log_%';

 我这边是已经打开了的。如果没有打开的话,log_bin的值会是OFF。

2、编辑配置文件

在myslq的安装目录下,找到my.ini

我这边使用的是宝塔面板,所以可以直接操作

在mysqld下面添加

#Binary Logging
log-bin=mysql-bin   
binlog-format=Row

其他的配置

指定他的日志位置  

log-bin=/www/server/data/mysql-bin

expire_logs_days= 7 #binlog过期清理时间;

max_binlog_size = 100m #binlog每个日志文件大小;

binlog_cache_size = 4m #binlog缓存大小;

max_binlog_cache_size = 512m #最大binlog缓存大小。

3.重启mysql(管理员的身份)

net stop mysql
net start mysql

1.2 赋予账号CDC权限

我这里偷了个懒,直接使用了管理员账号。

最后,测试通过。然后我么们创建任务进行数据同步。

--数据同步

1.任务配置

本次任务采用“全量+增量同步”模式,写入类型为增量写入。配置如下:

2.全量同步数据

数据同步我会从数据同步速度、资源占用、以及数据准确率三个方面进行测评。

话不多说,开干!

2.1 数据同步速度

本次执行时间:2021-08-06 11:03:13

本次结束时间:2021-08-06 11:23:38

总输出:440181

总输入:440181

 

44万数据,所用时间为20分钟。

从事件统计可以看出,前面大约会先读取30K条数据,之后读取与插入基本是同时进行,每次读取1K行,然后进行插入。

2.2 占用资源

 

 

 我这边设置的是每次读取1000行,所以可以看到系统资源基本上没有波动。

系统磁盘,CPU都是与开启同步任务前没有什么差异,几乎感觉不到在运行。

之后为了速度可以设置单次读取10000行甚至更多,可以根据实际需求调整。

2.3 同步准确率

从TapData官方提供的数据来看,是没有异常行的。

然后我们进行了数据校验,发现行数是与原表一致的。

之后博主导出了部分数据,进行了对比,目标数据与原表数据也都是一致的。

同步的时候,目标表是不存在,所以需要同步前新建,但是很奇怪,我给的是管理员权限,还是报错了,然后我手动创建了一下,就可以正常同步了,报错在下面,有兴趣的博友可以研究指点下。

Automatically create target table failed, job name: user_1, err: Create table failed, table/fields/tableName is empty, table: RelateDataBaseTable{table_name='t_user_Tap', fields=[], cdc_enabled=true}, stacks: io.tapdata.manager.TransformerJobManager.createTargetTable(TransformerJobManager.java:246)
io.tapdata.manager.TransformerJobManager.createTargetTableByMapping(TransformerJobManager.java:183)
io.tapdata.manager.TransformerJobManager.initTargetDB(TransformerJobManager.java:154)
io.tapdata.manager.TransformerJobManager.prepare(TransformerJobManager.java:128)
io.tapdata.Schedule.TransformerManager.scanJob(TransformerManager.java:256)
sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:65)
org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)

3. 增量数据同步

博主这边向源数据表中加入20K条数据,然后观察数据同步速度。

同步速度依旧保持在1000条每次,所以数据与之前的全量更新相差不多。这边就不写详细的过程了。

--使用总结

 从数据同步速度、资源占用、以及数据准确率三个方面来看的话,TapData表现是比较优秀的。创新性的将binlog作为同步用,解决了资源占用以及数据准确率问题,同时自研的Agent又能保证同步频率,属实是一套优秀的数据同步解决方案。实际应用下,可以很完美的解决掉公司的数据孤岛问题。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值