1、框架说明
用于读取mysql的binlog日志文件,将日志文件发到rocketMq,消费端可以订阅主题,对消息进行处理。这种方式 可以使多个应用订阅数据库变更数据。各个应用根据自己的业务逻辑处理对应的数据表即可。
1、结构流程图
图解说明:
1、mysql数据库开启Binary log操作日志记录功能,方便数据恢复,数据备份使用;
2、通过中间件mysql-binlog-connector-java读取日志文件,将日志文件解析成JSON格式;
3、解析完成数据后将日志文件发送到RocketMQ对应的主题上;
4、其他系统通过对主题的订阅,RocketMq将消息推送到对应的消费端,消费端收到消息后进行数据处理;
2、数据流图
图解说明:
通过rocketMq里面获取最新的读取mysql的日志文件名称、读取的日志文件位置;如果消息队列里面没有记录
信息,默认获取mysql最新的日志记录位置;在这期间会将数据库的表信息读取到放在内存中,以方便读取到
日志后对应的数据进程组合;
rocketMq将日志文件、位置发送给同步器,中间件mysql-binlog-connector-java组织数据发送给mysql数据
库,同时注册监听事件;
MySql收到请求后将日志数据发放给同步器,同步器解析数据,累积数据组成事务对象;
将“下一个同步位置”和日志数据发放给rocketMq;
将最新的位置记录在消息队列最新的数据中,方便下次读取时,进行获取位置;
3、部署步骤
在MySQL上创建一个具有同步权限的账户,Binlog要设置成row格式;
log-bin=mysql-bin #添加这一行就ok binlog-format=ROW #选择row模式
在rocketMQ上创建一个主题,该主题要求只有一个队列,对于读取的顺序性有保证;
配置RocketMQ-MySQL.conf文件信息;
mysqlAddr=127.0.0.1 mysqlPort=3306 mysqlUsername=root mysqlPassword=Root@123 mqNamesrvAddr=127.0.0.1:9876 mqTopic=mysql_Topic #startType= #binlogFilename= #nextPosition= #maxTransactionRows=
运行Replicator.java 文件;
创建消费者,消费消息;
2、Mysql的Binlog
1、二进制日志(binlog)
binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志。
2、日志用处
- 搭建复制架构的时候,需要binary log 来记录数据库的修改event;
- 数据库宕机恢复使用;
- 异常操作,紧急恢复数据使用;
3、Binlog常见格式
格式 | 日志内容 | 优点 | 缺点 |
---|---|---|---|
Row 模式 | 日志中会记录每一行数 据被修改的形式,然后在slave 端再对相同的数据进行修改 | 在row level 模式下,bin-log中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条被修改。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。不会出现某些特定的情况下的存储过程或function,以及trigger的调用和触发无法被正确复制的问题 | row level ,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,会产生大量的日志内容 |
Statement模式 | 每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行 | *statement level下的优点首先就是解决了row level下的缺点,不需要记录每一行数据的变化,减少bin-log日志量,节约IO,提高性能,因为它只需要在Master上锁执行的语句的细节,以及执行语句的上下文的信息。 | 由于只记录语句,所以,在statement level 下 已经发现了有不少情况会造成MySQL的复制出现问题,主要是修改数据的时候使用了某些定的函数或者功能的时候会出现。 |
Mixed | MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志格式,也就是在Statement和Row之间选择一种。 | 以上两种方式的结合 |