vlambda
2020-05-26

浅谈MySQL Binlog 解析工具 Maxwell

前言：

前段时间用上了公司的Maxwell去监控特定Mysql库表下的Binlog，所谓前人栽树，后人乘凉，乘着乘着可能就容易感冒了～所以，最近抽了点时间回头好好看了一下这个工具，也在这个过程中遇到了一些新的问题，在这里做一点记录。

如何配置Mysql 开启Binlog

参考官网：http://maxwells-daemon.io/quickstart/

修改 /etc/my.cnf 配置文件

//确保已配置server_id，并且已启用基于行的replication[mysqld]server-id=1log-bin=masterbinlog_format=row

创建Maxwell数据库与用户，赋予 maxwell 库的一些权限，并重启Mysql

create database maxwell;mysql> CREATE USER 'maxwell'@'%' IDENTIFIED BY '123456';mysql> GRANT ALL ON maxwell.* TO 'maxwell'@'%';mysql> GRANT SELECT, REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'maxwell'@'%'; FLUSH PRIVILEGES

如何开启Maxwell多个实例

以多个配置文件的方式进行加载：路径：/opt/maxwell/conf/**.properties

浅谈MySQL Binlog 解析工具 Maxwell

**.properties:

# maxwell metadatauser= #mysql 用户名password= #mysql 密码host= #mysql 地址jdbc_options=serverTimezone=Asia/Shanghai#mysql jdbc connection optionsschema_database=maxwell # Maxwell用于维护的schema和position将使用的数据库client_id= ** #用于标识Maxwell实例的唯一字符串
# sync database config#output_binlog_position=true 是否在输出的json流中，包含binlog filename:postion。默认 falseoutput_ddl=true #是否在输出的json流中，包含ddl语句。默认 falsereplication_host=#监听的主机replication_user=#用户名replication_password=#密码filter=exclude: *.*,include:bf_hive.* #过滤器#filter=include: *.*
# kafka configproducer=kafkaproducer_partition_by=primary_key #输入到kafka/kinesis的分区函数kafka_topic=#kafka topickafka_partition_hash=murmur3 #选择kafka分区时使用的hash方法kafka_key_format=hashkafka.bootstrap.servers=#kafka 集群列表，HOST:PORT[,HOST:PORT]log_level=info

启动：

nohup /opt/maxwell-1.19.2/bin/maxwell --config /opt/maxwell-1.19.2/conf/****.properties > /opt/maxwell-1.19.2/logs/***.log 2>&1 &

开发中遇到的问题

在对相关数据库表进行监控的时候，发现怎么时间类型的数据，在写到binlog的时候整整相差了八个小时，仔细对比后，发现只限TimeStamp字段类型的数据，查阅相关资料后发现：

观点一：时区相差8小时：TIMESTAMP类型数据采集时，会有八小时的时差，这个只能通过更改源码的方式解决。————————————————参考文档：https://blog.csdn.net/qq_32641659/article/details/105195948观点二：maxwell对时间类型（datetime, timestamp, date）都是当做字符串处理的，这也是为了保证数据一致(比如0000-00-00 00:00:00这样的时间在timestamp里是非法的，但mysql却认，解析成java或者python类型就是null/None)。如果MySQL表上的字段是 timestamp 类型，是有时区的概念（show variables like '%time_zone%';），binlog解析出来的是标准UTC时间，但用户看到的是本地时间。比如 f_create_time timestamp 创建时间是北京时间 2018-01-05 21:01:01，那么mysql实际存储的是 2018-01-05 13:01:01，binlog里面也是这个时间字符串。如果不做消费者不做时区转换，会少8个小时。与其每个客户端都要考虑这个问题，我觉得更合理的做法是提供时区参数，然后maxwell自动处理时区问题，否则要么客户端先需要知道哪些列是timestamp类型，或者连接上原库缓存上这些类型。————————————————参考文档：https://blog.csdn.net/wwwdc1012/article/details/88388552