Question

使用Debezium 0.7从MySQL读取但在初始快照阶段获得刷新超时和OutOfMemoryError错误。看下面的日志，似乎连接器试图一次写出太多消息：

WorkerSourceTask{id=accounts-connector-0} flushing 143706 outstanding messages for offset commit   [org.apache.kafka.connect.runtime.WorkerSourceTask]
WorkerSourceTask{id=accounts-connector-0} Committing offsets   [org.apache.kafka.connect.runtime.WorkerSourceTask]
Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
WorkerSourceTask{id=accounts-connector-0} Failed to flush, timed out while waiting for producer to flush outstanding 143706 messages   [org.apache.kafka.connect.runtime.WorkerSourceTask]

想知道大型数据库（＆gt; 50GB）的正确设置是http://debezium.io/docs/connectors/mysql/#connector-properties。我对小型数据库没有这个问题。简单地增加超时并不是一个好策略。我目前正在使用默认的连接器设置。

更新

按照以下建议更改设置，它解决了问题：

OFFSET_FLUSH_TIMEOUT_MS: 60000  # default 5000
OFFSET_FLUSH_INTERVAL_MS: 15000  # default 60000
MAX_BATCH_SIZE: 32768  # default 2048
MAX_QUEUE_SIZE: 131072  # default 8192
HEAP_OPTS: '-Xms2g -Xmx2g'  # default '-Xms1g -Xmx1g'

Answer 1

这是一个非常复杂的问题 - 首先，Debezium Docker图像的默认内存设置非常低，所以如果你使用它们，可能需要增加它们。

接下来，有多个因素在起作用。我建议采取以下措施。

增加N'和max.batch.size - 减少提交次数
增加max.queue.size - 为处理累计记录提供连接时间
减少offset.flush.timeout.ms - 应减少累积偏移量

不幸的是，在后台潜伏着issue KAFKA-6551仍然会造成严重破坏。

Answer 2

加入Jiri所说的话：

Debezium bugtracker现在有一个未解决的问题，如果您有关于根本原因，日志或复制的更多信息，请随时提供。

对我来说，改变Jiri在评论中提到的价值并没有解决问题。唯一可行的解决方法是在同一个worker上创建多个连接器，每个连接器负责所有表的子集。为此，您需要启动连接器1，等待快照完成，然后启动连接器2，依此类推。在某些情况下，当较晚的连接器开始快照时，较早的连接器将无法刷新。在这些情况下，您可以在完成所有快照后重新启动工作程序，并且连接器将再次从binlog中获取（确保您的快照模式为＆＃34; when_needed＆＃34;！）。

Answer 3

我可以确认Jiri Pechanec在上面发布的答案已经解决了我的问题。这是我正在使用的配置：

在worker.properties配置文件中设置的kafka connect worker配置：

offset.flush.timeout.ms=60000
offset.flush.interval.ms=10000
max.request.size=10485760

通过curl请求传递的Debezium配置将其初始化：

max.queue.size = 81290
max.batch.size = 20480

我们的暂存MySQL db（〜8GB）没有遇到这个问题，因为数据集要小得多。对于生产数据集（约80GB），我们必须调整这些配置。

希望这会有所帮助。

MySQL

更新

3 个答案: