MySQL实时同步到Elasticsearch实现方案 —— canal(兼容ES5.X)

首先看一下canal的实现原理:

 

 

  • canal 模拟 MySQL slave 的交互协议,伪装自己为 MySQL slave ,向 MySQL master 发送dump 协议
  • MySQL master 收到 dump 请求,开始推送 binary log 给 slave (即 canal )
  • canal 解析 binary log 对象(原始为 byte 流)

怎么使用

这里只记录需要使用过程中需要注意的地方,具体用法不在此赘述,可以参考canal的wiki:https://github.com/alibaba/canal

一、数据库配置:

  • 需要先开启 Binlog 写入功能,配置 binlog-format 为 ROW 模式,my.cnf 中配置如下

log-bin=mysql-bin # 开启 binlog

 

binlog-format=ROW # 选择 ROW 模式 server_id=1 # 配置 MySQL replaction 需要定义,不要和 canal 的 slaveId 重复

  • 授权 canal 链接 MySQL 账号具有作为 MySQL slave 的权限, 如果已有账户可直接 grant

CREATE USER canal IDENTIFIED BY 'canal'

GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';

-- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ;

FLUSH PRIVILEGES;

二、canal server端:

1. conf/canal.properties下修改端口

 

2.  可以配置destinations(默认为example,多个以逗号隔开),这个对应conf下面的文件夹order

 

3. order文件夹中的instance.properties,可以进行消费通道的配置:

 

三、canal client端:

canal 1.1.1版本之后,自带了适配器,不用写任何java代码,只需要写几个SQL脚本就可以直接实现同步,简单同步逻辑的可以考虑使用,比如单表同步、多表简单关联,友情提醒请看文章末尾

canal adapter 的 Elasticsearch 版本支持6.x.x以上,但是目前公司使用的es为5.3.3,官方宣称可以通过更改依赖即可适配低版本的es,但是还有一个地方需要调整,具体改动如下:

  1. 先将client-adapter中elasticsearch下的pom文件中依赖的elasticsearch相关组件的版本号降至5.X
  2. com.alibaba.otter.canal.client.adapter.es.ESAdapter类中

    transportClient.addTransportAddress(new TransportAddress(InetAddress.getByName(host.substring(0, i)),

        Integer.parseInt(host.substring(i + 1))));

    修改成:
     

    transportClient.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(host.substring(0, i)),

        Integer.parseInt(host.substring(i + 1))));

    3. 重新编译

    mvn clean install -Dmaven.test.skip -Denv=release

另外在同步SQL上面也有很多限制,下面是官方文档的:

  1. 主表不能为子查询语句
  2. 只能使用left outer join即最左表一定要是主表
  3. 关联从表如果是子查询不能有多张表
  4. 主sql中不能有where查询条件(从表子查询中可以有where条件但是不推荐, 可能会造成数据同步的不一致, 比如修改了where条件中的字段内容)
  5. 关联条件只允许主外键的'='操作不能出现其他常量判断比如: on a.role_id=b.id and b.statues=1
  6. 关联条件必须要有一个字段出现在主查询语句中比如: on a.role_id=b.id 其中的 a.role_id 或者 b.id 必须出现在主select语句中


除此之外,在使用过程中,还发现了一些其它未说明的限制和问题

1. _index只支持索引名称,不支持alias,在索引需要重构修改名称的时候,这里也需要进行修改。

2. 查询语句的字段大小写必须跟数据库中一致,如图中的ORDER_ID,如不指定,不会报错,但是查不出数据。

3. 在某一个表的数据时,会删除整个文档,比如删除了order_payment,那么会整个order_header文档。

5. 更新时查询不支持非数字类型主键,这个是由于拼接SQL字符串导致,已通过修改拼接代码解决。

6. 有一种业务场景,就是修改供应商或者维修厂的名称时,会涉及大量的文档更新,看了下原来的代码的代码中使用了批处理,但是速度奇慢,后续把代码注释掉之后,速度却得到了质的提升,无解。

注意:

对于官方提供的canal adapter,个人建议酌情使用,在非常简单的单表同步或者多表简单关联,可以考虑使用,能够很大程度的节省开发时间

在订单查询优化过程中,早期一直在使用canal adapter,但是因为订单的业务同步关联比较复杂,在对源码进行了多次修改才适配了订单数据的同步,另外,canal adapter在大多数场景下都会进行回表查询,这对同步效率也会有一定的影响。

在后面演示环境的DTS数据订阅处理时,发现有些代码完全可以为测试环境的canal同步所用,考虑到后续同步的灵活性,决定放弃了官方的adapter,自己写一套adapter。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章