Таймаут сброса Debezium и ошибки OutOfMemoryError с MySQL

Использование 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-properties для больших баз данных (> 50 ГБ). У меня не было этой проблемы с небольшими базами данных. Простое увеличение тайм-аута не кажется хорошей стратегией. В настоящее время я использую настройки коннектора по умолчанию.

Обновлять

Изменил настройки, как предложено ниже, и проблема устранилась:

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'

mysql java apache-kafka apache-kafka-connect debezium
person Kamil Sindi    schedule 17.04.2018    source источник

Ответы (3)


arrow_upward
8
arrow_downward

Это очень сложный вопрос - во-первых, настройки памяти по умолчанию для образов Debezium Docker довольно низкие, поэтому, если вы их используете, может потребоваться их увеличить.

Далее, в игре есть несколько факторов. Рекомендую сделать следующие шаги.

  1. Увеличить max.batch.size и max.queue.size - уменьшить количество коммитов
  2. Увеличить offset.flush.timeout.ms - дает время Connect для обработки накопленных записей
  3. Уменьшить offset.flush.interval.ms - должно уменьшить количество накопленных смещений

К сожалению, за кулисами скрывается проблема KAFKA-6551, которая все еще может нанести ущерб .

person Jiri Pechanec    schedule 17.04.2018
comment
Обратите внимание, что параметры Debezium (max.batch.size, max.queue.size) должны быть указаны как параметры соединителя; указание их как переменных env не будет работать (это поддерживается только для настроек, определенных Kafka (Connect). - person Gunnar; 11.07.2018
comment
привет, я читаю здесь документацию debezium.io/documentation/reference/assemblies/, и я не вижу offset.flush.timeout.ms или offset.flush.interval.ms параметров конфигурации. Откуда вы их берете? - person lollerskates; 11.03.2020
comment
@lollerskates - это конфигурация работника подключения. взгляните на это: docs.confluent.io/current/connect/references/ allconfigs.html - person sarah; 13.07.2020

arrow_upward
2
arrow_downward

Чтобы добавить к сказанному Иржи:

Теперь в Debezium bugtracker есть открытая проблема, если у вас есть дополнительная информация о основные причины, журналы или воспроизведение, не стесняйтесь предоставлять их там.

Для меня изменение значений, которые Иржи упомянул в своем комментарии, не решило проблему. Единственный рабочий обходной путь - создать несколько коннекторов на одном и том же работнике, каждая из которых отвечает за подмножество всех таблиц. Чтобы это сработало, вам нужно запустить коннектор 1, дождаться завершения создания снимка, затем запустить коннектор 2 и так далее. В некоторых случаях более ранний соединитель не может очистить, когда более поздний соединитель начинает делать снимок. В таких случаях вы можете просто перезапустить воркера после того, как все снимки будут завершены, и коннекторы снова заберутся из бинлога (убедитесь, что ваш режим снимка - when_needed!).

person MrTrustworthy    schedule 23.04.2018

arrow_upward
1
arrow_downward

Я могу подтвердить, что опубликованный выше ответ Иржи Печанец решил мои проблемы. Я использую следующие конфигурации:

kafka connect worker config, установленный в конфигурационном файле worker.properties:

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

Конфиги Debezium прошли через запрос curl для его инициализации:

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

Мы не столкнулись с этой проблемой с нашей промежуточной базой данных MySQL (~ 8 ГБ), потому что набор данных намного меньше. Для производственного набора данных (~ 80 ГБ) нам пришлось скорректировать эти конфигурации.

Надеюсь это поможет.

person mahdir24    schedule 19.09.2019