logstash_output_kafka:Mysql同步Kafka深入详解

本文涉及的产品
RDS Agent(兼容OpenClaw),2核4GB
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介: 实际业务场景中,会遇到基础数据存在Mysql中,实时写入数据量比较大的情景。迁移至kafka是一种比较好的业务选型方案。

image.png

链接

image.png

而mysql写入kafka的选型方案有:

方案一:logstash_output_kafka 插件。

方案二:kafka_connector。

方案三:debezium 插件。

方案四:flume。

方案五:其他类似方案。


其中:debezium和flume是基于mysql binlog实现的。

如果需要同步历史全量数据+实时更新数据,建议使用logstash。


1、logstash同步原理

常用的logstash的插件是:logstash_input_jdbc实现关系型数据库到Elasticsearch等的同步。

实际上,核心logstash的同步原理的掌握,有助于大家理解类似的各种库之间的同步。

logstash核心原理:输入生成事件,过滤器修改它们,输出将它们发送到其他地方。

logstash核心三部分组成:input、filter、output。

image.png

input { }

filter { }

output { }

1

2

3

##1.1 input输入

包含但远不限于:


jdbc:关系型数据库:mysql、oracle等。

file:从文件系统上的文件读取。

syslog:在已知端口514上侦听syslog消息。

redis:redis消息。 beats:处理 Beats发送的事件。

kafka:kafka实时数据流。

1.2 filter过滤器

过滤器是Logstash管道中的中间处理设备。您可以将过滤器与条件组合,以便在事件满足特定条件时对其执行操作。

可以把它比作数据处理的ETL环节。

一些有用的过滤包括:


grok:解析并构造任意文本。Grok是目前Logstash中将非结构化日志数据解析为结构化和可查询内容的最佳方式。有了内置于Logstash的120种模式,您很可能会找到满足您需求的模式!

mutate:对事件字段执行常规转换。您可以重命名,删除,替换和修改事件中的字段。

drop:完全删除事件,例如调试事件。

clone:制作事件的副本,可能添加或删除字段。

geoip:添加有关IP地址的地理位置的信息。

1.3 output输出

输出是Logstash管道的最后阶段。一些常用的输出包括:


elasticsearch:将事件数据发送到Elasticsearch。

file:将事件数据写入磁盘上的文件。

kafka:将事件写入Kafka。

详细的filter demo参考:https://github.com/hellosign/logstash-fundamentals/blob/master/examples/complex_logstash.md


2、logstash_output_kafka同步Mysql到kafka配置参考

input {

   jdbc {

     jdbc_connection_string => "jdbc:mysql://192.168.1.12:3306/news_base"

     jdbc_user => "root"

     jdbc_password => "xxxxxxx"

     jdbc_driver_library => "/home/logstash-6.4.0/lib/mysql-connector-java-5.1.47.jar"

     jdbc_driver_class => "com.mysql.jdbc.Driver"

     #schedule => "* * * * *"

     statement => "SELECT * from news_info WHERE id > :sql_last_value  order by id"

     use_column_value => true

     tracking_column => "id"        

     tracking_column_type => "numeric"

     record_last_run => true

     last_run_metadata_path => "/home/logstash-6.4.0/sync_data/news_last_run"    


   }

}


filter {

  ruby{

       code => "event.set('gather_time_unix',event.get('gather_time').to_i*1000)"

   }

   ruby{

       code => "event.set('publish_time_unix',event.get('publish_time').to_i*1000)"

   }

 mutate {

   remove_field => [ "@version" ]

   remove_field => [ "@timestamp" ]

   remove_field => [ "gather_time" ]

   remove_field => [ "publish_time" ]

 }

}


output {

     kafka {

           bootstrap_servers => "192.168.1.13:9092"

           codec => json_lines

           topic_id => "mytopic"


   }

   file {

           codec => json_lines

           path => "/tmp/output_a.log"

   }

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

以上内容不复杂,不做细讲。

注意:

Mysql借助logstash同步后,日期类型格式:“2019-04-20 13:55:53”已经被识别为日期格式。


code =>

“event.set(‘gather_time_unix’,event.get(‘gather_time’).to_i*1000)”,


是将Mysql中的时间格式转化为时间戳格式。


3、坑总结

3.1 坑1字段大小写问题

from星友:使用logstash同步mysql数据的,因为在jdbc.conf里面没有添加 lowercase_column_names

=> “false” 这个属性,所以logstash默认把查询结果的列明改为了小写,同步进了es,所以就导致es里面看到的字段名称全是小写。


最后总结:es是支持大写字段名称的,问题出在logstash没用好,需要在同步配置中加上 lowercase_column_names => “false” 。记录下来希望可以帮到更多人,哈哈。


3.2 同步到ES中的数据会不会重复?

想将关系数据库的数据同步至ES中,如果在集群的多台服务器上同时启动logstash。


解读:实际项目中就是没用随机id 使用指定id作为es的_id ,指定id可以是url的md5.这样相同数据就会走更新覆盖以前数据


3.3 相同配置logstash,升级6.3之后不能同步数据。

解读:高版本基于时间增量有优化。


tracking_column_type => "timestamp"

1

应该是需要指定标识为时间类型,默认为数字类型numeric


3.4 ETL字段统一在哪处理?

解读:可以logstash同步mysql的时候sql查询阶段处理,如:select a_value as avalue***。

或者filter阶段处理,mutate rename处理。


mutate {

       rename => ["shortHostname", "hostname" ]

   }


1

2

3

4

或者kafka阶段借助kafka stream处理。


4、小结

相关配置和同步都不复杂,复杂点往往在于filter阶段的解析还有logstash性能问题。

需要结合实际业务场景做深入的研究和性能分析。

有问题,欢迎留言讨论。

新的实现:https://debezium.io/blog/2018/01/17/streaming-to-elasticsearch/

mysql2mysql:https://my.oschina.net/u/2601303/blog/1503835

推荐开源实现:https://github.com/Lunatictwo/DataX


推荐阅读:

1、实战 | canal 实现Mysql到Elasticsearch实时增量同步

2、干货 | Debezium实现Mysql到Elasticsearch高效实时同步

3、一张图理清楚关系型/非关系型数据库与Elasticsearch同步

相关文章
|
安全 关系型数据库 MySQL
如何将数据从MySQL同步到其他系统
【10月更文挑战第17天】如何将数据从MySQL同步到其他系统
2088 0
|
8月前
|
NoSQL 算法 Redis
【Docker】(3)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!
Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
853 6
|
关系型数据库 MySQL Shell
MySQL 备份 Shell 脚本:支持远程同步与阿里云 OSS 备份
一款自动化 MySQL 备份 Shell 脚本,支持本地存储、远程服务器同步(SSH+rsync)、阿里云 OSS 备份,并自动清理过期备份。适用于数据库管理员和开发者,帮助确保数据安全。
|
消息中间件 关系型数据库 MySQL
基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成
基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成
1481 0
|
消息中间件 关系型数据库 MySQL
基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成
本教程展示如何使用Flink CDC YAML快速构建从MySQL到Kafka的流式数据集成作业,涵盖整库同步和表结构变更同步。无需编写Java/Scala代码或安装IDE,所有操作在Flink CDC CLI中完成。首先准备Flink Standalone集群和Docker环境(包括MySQL、Kafka和Zookeeper),然后通过配置YAML文件提交任务,实现数据同步。教程还介绍了路由变更、写入多个分区、输出格式设置及上游表名到下游Topic的映射等功能,并提供详细的命令和示例。最后,包含环境清理步骤以确保资源释放。
1120 2
基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成
|
监控 关系型数据库 MySQL
Flink CDC MySQL同步MySQL错误记录
在使用Flink CDC同步MySQL数据时,常见的错误包括连接错误、权限错误、表结构变化、数据类型不匹配、主键冲突和
646 17
|
消息中间件 存储 缓存
kafka 的数据是放在磁盘上还是内存上,为什么速度会快?
Kafka的数据存储机制通过将数据同时写入磁盘和内存,确保高吞吐量与持久性。其日志文件按主题和分区组织,使用预写日志(WAL)保证数据持久性,并借助操作系统的页缓存加速读取。Kafka采用顺序I/O、零拷贝技术和批量处理优化性能,支持分区分段以实现并行处理。示例代码展示了如何使用KafkaProducer发送消息。
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
658 1
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
506 1
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
1657 9

推荐镜像

更多