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

账号权限问题 [已解决]
canal的策略是模拟了MySQL Slave的行为，因此需要有SELECT, REPLICATION SLAVE, REPLICATION CLIENT的权限

解决思路：

目前aliyun上的RDS默认创建的账号已经自带了这些权限，针对RDS 5.6/5.7的高权限实例，可以用root账号额外进行一下授权，授权操作可参考[QuickStart]
binlog被删除的问题 [已解决]
对应的binlog清理策略, 超过18小时之后会删除并备份到oss之上，如果canal任务停止超过18小时就会遇到xx类似错误，

解决思路：

RDS默认提供了一段时间oss binlog的下载能力，参考文档。canal可以识别位点中的时间戳，对比一下RDS中show binary logs里最早的一条binlog，如果不满足则会通过oss接口进行下载到本机进行解析，追平历史binlog之后再切换到RDS binlog中继续消费【canal代码会支持】
image
主备切换导致的问题 [已解决]
一般云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.要保存同步标记