MySQL Binlog
要通过 MySQL binlog 将 MySQL 的数据同步给 ES， 我们只能使用 row 模式的 binlog。如果使用 statement 或者 mixed format，我们在 binlog 里面只能知道对应的 query 语句，完全没法知道这条语句到底改了啥数据，所以要从 binlog 里面得到实际的数据，只能用 row 模式。
Row 模式还可以设置 full，noblob 以及 minimal 三种 image 模式，后面两种主要是为了减少空间占用，默认是 full。个人其实最喜欢 full 模式，这样数据最全，而且也觉得空间占用对于现在的硬盘来说不是特别大的问题，毕竟我们还有定期清理 binlog 的机制。
同步 MySQL binlog 就很简单了，按照 MySQL replication 的协议，自己写一个客户端，模拟成 MySQL slave，注册给 MySQL master 就可以了。MySQL master 会实时的将数据的更新通过 binlog event 发送给 slave，然后我们自己解析 event 之后就能得到实际的数据了。
具体实现这里不做过多说明，大家可以参考 MySQL Client/Server Protocol 细致的了解 MySQL 的 protocol，binlog events 等相关知识。其中在 go-mysql项目里面实现了相关的 replication功能。
MySQL dump
如果是一个新建 MySQL，我们当然可以通过 binlog 的方式方便的同步数据。但如果我们想同步一个已经运行一段时间的 MySQL ，就可能会有问题了。因为这时候早期的 binlog 文件已经被删除，如果直接开始同步，我们就可能会缺失一部分早期更新的数据。
要解决这个办法也比较容易，参考 MySQL 通用的 backup 方式，我们可以先使用 mysqldump 获取当前 MySQL 的整个 snapshot，直接解析生成的 dump 文件，就能得到当前所有的数据。然后在从这个 snapshot 对应的 binlog position 位置开始同步。
整个这套流程也在 go-mysql 的 canal 里面实现。
另外一种方式
可以使用 mtime 时间戳进行控制，增加一个辅助标量 flag（标记是否删除），这样在索引系统中定时通过 mtime 过滤数据，在通过 flag 标志位指示是否已经被删除的数据；这里就会有两种方案去处理：
1. 当 flag 标记为删除，则在执行索引的时候使用 delete 直接将 ElasticSearch 中的数据删除掉
2. 不区分 flag 标签，直接索引到 ElasticSearch 中去，在搜索的时候将 flag 为删除的数据过滤掉