MySQL的Debezium刷新超时和OutOfMemoryError错误

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]

想知道正确的设置是什么http://debezium.io/docs/connectors/mysql/#connector-大型数据库的属性(

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

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

为了补充Jiri所说的话：

Debezium bugtracker中现在有一个公开问题，如果您有任何关于根本原因、日志或复制的更多信息，请随时提供。

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

Answer 2

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

kafka connect worker在worker中配置设置。属性配置文件：

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

Debezium configs通过curl请求对其进行初始化：

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

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

希望这有帮助。

Answer 3

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

接下来，有多个因素在起作用。我建议做以下步骤。

1. 增加max.batch。大小和最大队列。大小-减少提交次数

不幸的是，Kafka-6551在后台潜伏着一个问题，仍然可能造成严重破坏。