ETL同步

首先明确一下针对这类云MySQL的binlog订阅，通常会面临的几个问题

1. 账号权限问题 [已解决]
   canal的策略是模拟了MySQL Slave的行为，因此需要有SELECT, REPLICATION SLAVE, REPLICATION CLIENT的权限
   
   解决思路：
   
   目前aliyun上的RDS默认创建的账号已经自带了这些权限，针对RDS 5.6/5.7的高权限实例，可以用root账号额外进行一下授权，授权操作可参考[QuickStart]
   binlog被删除的问题 [已解决]
2. 对应的binlog清理策略, 超过18小时之后会删除并备份到oss之上，如果canal任务停止超过18小时就会遇到xx类似错误，
   
   解决思路：
   
   RDS默认提供了一段时间oss binlog的下载能力，参考文档。canal可以识别位点中的时间戳，对比一下RDS中show binary logs里最早的一条binlog，如果不满足则会通过oss接口进行下载到本机进行解析，追平历史binlog之后再切换到RDS binlog中继续消费 【canal代码会支持】
   image
3. 主备切换导致的问题 [已解决]
   一般云MySQL的主备方案都采用了vip模式，屏蔽了后端物理节点之间的主备切换，也就是对于canal来说只看到了单节点的MySQL ip，针对物理上进行主备切换时拿着老主库位点去订阅时会遇到xx类似错误
   
   解决思路:
   
   针对MySQL5.6+可以使用canal gtid的订阅方式(针对出现问题2时，需要进行本地binlog解析就无法很好的支持)，或者比较推荐的就是基于serverId自动识别主备切换，每次进行binlog订阅时，检查一下位点中的serverId和当前数据库节点的serverId是否一致，如果不一致说明服务端产生了主备切换，可以基于时间戳重新在新的主库中定位到对应的binlog，再继续后续的消费即可。ps. 这里定位位点时需要考虑binlog被删除的情况，参考问题2

同步方式

同步方式	优点	缺点
binlog	1.数据可以实时同步 2. 可以构建高可用系统 3. 不用关心表结构是否有同步标记字段 3. 可以监听多数据源(mysql)	1. 抽取器需要自己开发
定时任务	1. 有现成产品可以使用(Kettle) 自带输入转换输出	1. 基于定时任务数据实时性较差 2.要保存同步标记

ETL产品对比

https://blog.csdn.net/juceli/article/details/81448224

https://blog.csdn.net/weixin_38071106/article/details/88547660

image.png

image.png

canal

1. canal 1.x 解决了上述问题
2. canal 监听多数据源配置不同的canal.destinations
3. 支持表过滤canal.instance.filter.regex
4. HA基于ZK,主备非分片
5. Latest commit 2 days ago