服务迁移之《mysql数据同步问题》

我们大概是从2022年十月份开始进行拆分的。面对一百多个服务的时候，真的是无从下手，然后公司突然空降了一个从阿里出来的架构师，然后就带着我们大刀阔斧的整体迁移。

先是服务器购买阿里云的，然后从几个核心的服务开始迁移，发现会依赖很多的基础的原子服务。然后就开始迁移基础，基础服务迁移过来后，对应的很多中间件都要迁移到阿里云上。这样理论上分析是可行的，但是，当测试进行车机测试的时候发现，充电后计费数据在APP上没有显示。

然后就去追接口，这时候发现这个数据在车联。。原本没有拆分的时候，都在帆一云上，是可以直接查询的，现在迁移后，这个数据就没有过来。所以，这里面临的问题就是，要把帆一云上的车联的数据实时的同步过来。（刚开始整体迁移的时候，数据库是用阿里云的数据库同步工具同步的，服务迁移完成以后就会把这个同步工具给关了，这中间我们整体迁移一共经历了三次才成功）

增量数据实时同步，业界也有几种方案。其中架构师让我去调查一下解决方案，还推荐让我使用mysql-binlog-connector-javas这个组件去做个demo。这个组件虽然是具备了同步数据的基本功能，但是不够完美，它会存在以下问题：如果我们部署的服务是多个节点，我们还要去解决重复问题、负载均衡问题，还要自己去保证高可用问题。然后就去对比了一下canal，以下是考虑到的因素：

影响因素	组件方式	canal中间件
部署需要的资源	直接引入一个jar包	需要部署server，并且依赖于zk，然后使用client sdk
是否高可用	否	是
是否可扩展	不能，因为需要自己写代码控制防重问题	集群可扩展
是否能堆积消息	不能，需要自己写持久层才能堆积消息	自带堆积功能，重联续传
有序性	自己代码控制	server保证
并发性、高性能	全程手动控制，遇到集群只能分布式锁	server保证
安全性	自己代码控制，不确定	server保证

最终，使用了canal方案。然后就是一系列夸团队沟通协调，找了很多人才搞定了基础环境。比如：发邮件走流程进行资源申请；发邮件找车联团队相关技术开binglog同步权限和账号；发邮件找基础运维搭建基础环境； 发邮件找双方的安全进行开墙，打通网络；最后是找运维、测试搞定黑白盒测试，发布流水线上线服务；

 

最终上线以后数据是同步过来了，但是运行了一段时间以后突然发现服务开始出现错误日志了，然后发现ddl语句也通过来了，然后没有权限执行。最后经过约定，就是数据表变更的时候提前通知一下。理论上是不会变的。这里不是技术上不能同步表结构变更，是因为变更后会带来业务问题。