本文主要是介绍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 中配置如下
|
|
- 授权 canal 链接 MySQL 账号具有作为 MySQL slave 的权限, 如果已有账户可直接 grant
|
|
二、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，但是还有一个地方需要调整，具体改动如下：
- 先将client-adapter中elasticsearch下的pom文件中依赖的elasticsearch相关组件的版本号降至5.X
-
com.alibaba.otter.canal.client.adapter.es.ESAdapter类中
transportClient.addTransportAddress(newTransportAddress(InetAddress.getByName(host.substring(0, i)),Integer.parseInt(host.substring(i +1))));修改成：
transportClient.addTransportAddress(newInetSocketTransportAddress(InetAddress.getByName(host.substring(0, i)),Integer.parseInt(host.substring(i +1))));3. 重新编译
mvn clean install -Dmaven.test.skip -Denv=release
另外在同步SQL上面也有很多限制，下面是官方文档的：
- 主表不能为子查询语句
- 只能使用left outer join即最左表一定要是主表
- 关联从表如果是子查询不能有多张表
- 主sql中不能有where查询条件(从表子查询中可以有where条件但是不推荐, 可能会造成数据同步的不一致, 比如修改了where条件中的字段内容)
- 关联条件只允许主外键的'='操作不能出现其他常量判断比如: on a.role_id=b.id and b.statues=1
- 关联条件必须要有一个字段出现在主查询语句中比如: 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）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
