使用Debezium 0.7读取MySQL时初始快照阶段遇Flush Timeout与OOM错误求助

我之前帮团队排查过一模一样的问题，核心就是初始快照阶段Debezium一次性拉取并缓存了过量数据，直接超出了Kafka Connect的处理能力和内存上限。结合你日志里显示的一次性flush 14万条消息的情况，给你几个针对性的调整方案：

1. 缩小Debezium快照的单次拉取行数 #

Debezium默认的snapshot.fetch.size是1024，对于数据量较大的表来说，这个值还是会导致短时间内生成大量待处理消息。你可以把这个参数调小，比如设置为500甚至200，让快照过程分批读取MySQL数据，降低内存瞬时压力。

在连接器配置里添加：

snapshot.fetch.size=500

2. 优化Kafka Connect的批量处理与内存配置 #

• 调整批量提交参数：修改Connect的worker.properties（或对应配置文件），限制每个批次的大小和提交频率，避免一次性堆积过多消息：

  batch.size=16384  # 每个批次的字节数，默认16KB，可根据实际场景微调
  linger.ms=500      # 等待攒批的时间，减少频繁小批量提交的开销
  max.request.size=10485760  # 单个请求的最大字节数，默认1MB，可改为10MB
  

• 增大Connect的堆内存：OutOfMemoryError本质是内存不足，初始快照需要处理全量数据，得给Connect分配足够的内存。启动Connect时调整KAFKA_HEAP_OPTS：

  export KAFKA_HEAP_OPTS="-Xmx4G -Xms2G"
  

3. 延长Offset Flush的超时时间 #

默认的offset.flush.timeout.ms是5000毫秒（5秒），当需要flush的消息量过大时，5秒可能不足以完成提交。把这个值调大，比如延长到30秒：

在Connect的worker.properties里添加：

offset.flush.timeout.ms=30000

简单来说，初始快照是全量拉取操作，默认配置在大数据量表前很容易撑爆内存或触发超时，通过缩小快照拉取批次、优化Connect批量参数、增加内存和延长超时这几个组合操作，基本就能解决你遇到的问题。

内容的提问来源于stack exchange，提问作者Kamil Sindi