背景
可参考github issue描述: https://github.com/alibaba/canal/issues/727
如果用户使用binlog解析工具,链接aliyun RDS需要解决几个方面的问题:
- 账号权限问题
- aliyun RDS早期控制台创建的账号,默认没有binlog dump需要的权限,目前创建的账号默认自带了权限,不需要做任何额外的处理,是否包含必须的权限,也可以直接查询show grants
- binlog被删除的问题
- aliyun RDS有自己的binlog日志清理策略,这个策略相比于用户自建mysql会更加激进,默认应该是18小时就会清理binlog并上传到oss上,可以在页面上进行调整,或者业务可以通过oss下载更早的binlog
- 主备切换导致的问题
- 一般云MySQL的主备方案都采用了vip模式,屏蔽了后端物理节点之间的主备切换,所以对于binlog dump来说你不知道连的是哪个后端mysql节点,需要自适应后端的主备切换过程
以上3条,基本对于所有的云模式的MySQL都适用,都需要binlog dump的程序进行支持或者适应. 目前canal 1.1.x版本之后都比较好的支持了aliyun RDS的binlog dump.
使用
vi conf/example/instance.properties
关注参数:
参数名字
|
参数说明
|
默认值
|
canal.aliyun.accessKey
|
aliyun账号的ak信息 (如果不需要在本地binlog超过18小时被清理后自动下载oss上的binlog,可以忽略该值)。注意:如果是1.1.0的老版本对应的参数名为canal.instance.rds.accesskey
|
无
|
canal.aliyun.secretKey
|
aliyun账号的sk信息
(如果不需要在本地binlog超过18小时被清理后自动下载oss上的binlog,可以忽略该值。注意:如果是1.1.0的老版本对应的参数名为canal.instance.rds.secretkey)
|
无
|
canal.instance.rds.instanceId
|
aliyun rds对应的实例id信息
(如果不需要在本地binlog超过18小时被清理后自动下载oss上的binlog,可以忽略该值)
|
无
|
实际例子:
#################################################
#enable gtid use true/false
canal.instance.gtidon=false
#position info
canal.instance.master.address=127.0.0.1:3306
canal.instance.master.journal.name=
canal.instance.master.position=
canal.instance.master.timestamp=
canal.instance.master.gtid=
#rds oss binlog
canal.instance.rds.accesskey=2zA12sL23cX230pS
canal.instance.rds.secretkey=iEl12120i341jv326ud23reULeIOSG
canal.instance.rds.instanceId=rm-bp1u38330lqe7989f
#table meta tsdb info
canal.instance.tsdb.enable=true
#username/password
canal.instance.dbUsername=canal
canal.instance.dbPassword=canal
canal.instance.connectionCharset=UTF-8
# table regex
canal.instance.filter.regex=.*\\..*
# table black regex
canal.instance.filter.black.regex=
#################################################
注意点:
- 相比于普通的mysql配置,多了rds oss binlog所需要的aliyun ak/sk/实例id等相关信息(如果不需要在本地binlog超过18小时被清理后自动下载oss上的binlog,可以忽略该值)