前言
- 项目模块
BinlogMiddleware
1、binlog中间件，负责解析binlog，把变动的数据以json形式发送到kafka队列。
KafkaMiddleware
2、kafka中间件，负责消费kafka队列中的Message，把数据写入Elasticsearch中。
- 基础服务
（1）Mysql
（2）Kafka（用于存放mysql变动消息，存放于Kafka队列）
（3）Elasticsearch
- 项目源码
码云：https://gitee.com/OrgXxxx/SyncMysqlToElasticsearch
1、开启mysql的binlog
（1）binlog简介
binlog,即二进制日志,它记录了数据库上的所有改变，并以二进制的形式保存在磁盘中；
它可以用来查看数据库的变更历史、数据库增量备份和恢复、Mysql的复制（主从数据库的复制）。
（2）Binary Log记录方式
Row Level
Binary Log会记录成每一行数据被修改的形式，然后在Slave端再对相同的数据进行修改。
如果修改了表的结构，那么binlog日志记录的是重新创建表，在插入字段、update等操作语句，而不是的alter的动作。
优点：在Row Level模式下，Binnary Log可以不记录执行的Query语句的上下文相关信息，只要记录哪一行修改了，修改成什么样子。Row Level会详细的记录下每一行数据的修改细节，而且不会出现某个特定情况下的存储过程，或Function，以及Trigger的调用和触发无法被正确复制问题。
缺点：产生大量的日志内容。
Statment Level
每一条会修改的SQL语句都会记录到Master的Binnary中。Slave端在复制的时候，SQL线程会解析成和原来Master端执行过相同的SQL语句，并再次执行。
优点：首先，解决了Row Level下的缺点，不须要记录每一行的数据变化，减少了Binnary Log日志量，节约了IO成本，提高了性能。
缺点：由于它是记录的执行语句，为了让这些语句在Slave端也能正确执行。那么它还必须记录每条语句在执行时的一些相关信息，即上下文信息，以保证所有语句在Slave端被执行的时候能够得到和在Master端执行时相同的结果。另外，由于MySQL发展比较快，很多新功能不断加入，使得MySQL复制遇到了不小的挑战，复制时设计的内容岳父在，越容易出bug。在Statement Level下，目前已发现不少的情况下会造成MySQL的复制问题。主要是在修改数据使用了某些特定的函数货功能后，出现，比如：Sleep()函数在有些版本中就不能正确的复制，在存储过程中使用了last_insert_id()函数，可能会使Slave和Master的到不一致的ID，等等。
Mixed Level
在Mixed模式下，MySQL会根据执行的每一条具体的SQL语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。除了MySQL认为通过Statement方式可能造成复制过程中Master和Slave之间产生不一致数据。(如特殊Procedure和Funtion的使用，UUID()函数的使用等特殊情况)时，它会选择ROW的模式来记录变更之外，都会使用Statement方式。
ps：在后续开发中将使用Row格式
（3）开启mysql的binlog
a.修改my.cnf配置
[mysqld]
log-bin=mysql-bin # 开启binlog
binlog-format=ROW # 设置Binary Log记录方式为Row
server_id=1 # 记住id 后续开发会使用
b.重启mysql
mysql.server restart
c.查看开启状态
输入 show variables like 'log_bin'; 查看binlog开启状态。如下图所示。
输入 show variables like 'binlog_format'; 查看Binary Log记录方式。如下图所示。
