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

本文主要是介绍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。

这篇关于MySQL实时同步到Elasticsearch实现方案 —— canal（兼容ES5.X）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---