编排任务
和实施前对比目前上线的数据源有 Oracle、MongoDB、MySQL、PostgreSQL、GBase。数据库集群数量达到10+套,同时支撑3条完整业务线运作,并发高峰达到 18w/秒。
有效解决了当时阻碍技术负责人执行的最大障碍:大数据量的数据同步工作,及落地后的数据管理。
新增业务时,用户技术人员只需要做简单的拖动就可以完成。减少了技术人员的开发工作,帮助技术人员将更多的时间聚焦在核心业务上。极大缩短了项目上线周期。
孤儿文档 现象在运行了一段时间后,在一次新应用接入后,发现接入的数据有重复,通过TD的数据比对工具发现源端 mongo 和目标端 mongodb 在相同表的数据量上确实存在差异。
这个事情对于数据同步工具来说是非常致命的,数据同步最核心的能力就是要保障数据的一致性,而数据同步工具的数据幂等性也是经过中国软件评测中心的测试认证的。
对于该现象的发生,我们团队非常重视,如果真是同步工具导致的数据不一致性,那就是致命bug。需要回归所有功能。
排查随机便在第一时间联系上用户技术,并开展了一系列的排查工作。
确认数据库类型排查第一步就是确认源端和目标端的数据库类型和操作系统配置。
本次出现数据重复的任务涉及到的数据库情况是:
源端数据库
mongo 3.2
单实例副本集
64c 256GB SAS硬盘
万兆光纤内网
目标端数据库
mongo 4.0
6分片集群
64c 256GB SAS硬盘
万兆光纤内网
找出重复数据既然有重复数据,那我们就要先找出这些数据来。
源端数据库是 mongo,目标端也是 mongo,这就比较好办了,写一套 js 脚本即可。这里会有一个坑,后面会说到,就是分片集群需要去每个节点上查,而不要在 mongos 上查。
脚本很简单,因为数据同步工具在同步的时候是会根据业务主键同步的,所以我就可以在目标端集合中,遍历每条数据,然后拿着业务主键去源端数据库查询,比对所有值。
这个过程会很慢,但只能等。
当然要注意的是,由于源端数据库是单节点,所以理论上应该同步一份数据出来作比对会好些,但是由于该业务还没上线,所以影响不大。而目标端数据的话是可以通过查找从节点数据进行比对的。
比对结果就是二十几张表一共 1kw 的数据,有十几万重复。看起来这个重复的数据量还不少。
这里我定义的重复数据就是相同的业务主键应该是数据唯一的,但在目标端却查到不止一条。
检查数据同步工具日志现在有了重复数据,就可以去数据同步工具日志里查询了。
在同步过程中是否有出现数据重复,或者 ERROR,如果发现有 duplicate key 字样,那就可以顺着这条记录往下排查。
但很遗憾,在日志中并没有发现类似字眼
检查 mongodb 日志数据同步工具日志无果,转战 mongodb 日志,通过查看 mongodb 日志,发现有大量的recvChunk 和 moveChunk 日志
看到这个,我一下子就不困了呀。
我简单给大家说下这段日志在干嘛。因为目标端 mongodb 是分片集群,分片中有一个很重要的概念叫块移动。分片集群是以数据块(chunk)为最小单位进行存储的,默认一个块可以存储64MB大小数据。