Проблемы настройки производственного кластера Apache kafka - PullRequest
0 голосов
/ 13 декабря 2018

Мы пытались настроить производственный уровень кластера Kafka на компьютерах AWS Linux, и до сих пор у нас не получалось.

Версия Kafka: 2.1.0

Машины:

5 r5.xlarge machines for 5 Kafka brokers.
3 t2.medium zookeeper nodes
1 t2.medium node for schema-registry and related tools. (a Single instance of each)
1 m5.xlarge machine for Debezium.

Конфигурация посредника по умолчанию:

num.partitions=15
min.insync.replicas=1
group.max.session.timeout.ms=2000000 
log.cleanup.policy=compact
default.replication.factor=3
zookeeper.session.timeout.ms=30000

Наша проблема в основном связана с огромными данными.Мы пытаемся перенести наши существующие таблицы в темы кафки, используя дебезиум.Многие из этих таблиц довольно большие и содержат более 50000000 строк.

До сих пор мы пробовали много вещей, но наш кластер каждый раз терпел неудачу по одной или нескольким причинам.

ERROR Uncaught исключениев запланированном задании 'isr-expiration' (kafka.utils.KafkaScheduler) org.apache.zookeeper.KeeperException $ SessionExpiredException: KeeperErrorCode = Время сеанса истекло для / brokers / themes / __ consumer_offsets / partitions / 0 / состояния в org.apache.zookeeper..create (KeeperException.java:130) в org.apache.zookeeper.KeeperException.create (KeeperException.java:54) ..

Ошибка 2:

]ИНФОРМАЦИЯ [Partition xxx.public.driver_operation-14 broker = 3] Кэшированный zkVersion [21] не равен значению в zookeeper, пропустите обновление ISR (kafka.cluster.Partition) [2018-12-12 14: 07: 26,551] INFO [Partition xxx.public.hub-14 broker = 3] Сокращение ISR с 1,3 до 3 (kafka.cluster.Partition) [2018-12-12 14: 07: 26,556] INFO [Partition xxx.public.hub-14 broker= 3] кешируется zkVersion [3] нетравный этому в zookeeper, пропустите обновление ISR (kafka.cluster.Partition) [2018-12-12 14: 07: 26,556] INFO [Partition xxx.public.field_data_12_2018-7 broker = 3] Сокращение ISR с 1,3 до 3(kafka.cluster.Partition)

Ошибка 3:

ulationLevel = READ_UNCOMMITTED, toForget =, metadata = (sessionId = 888665879, epoch = INITIAL)) (кафка.server.ReplicaFetcherThread) java.io.IOException: подключение к 3 было отключено до того, как ответ был прочитан в org.apache.kafka.clients.NetworkClientUtils.sendAndReceive (NetworkClientUtils.java:97)

Еще немногоошибки:

  1. Частые отключения среди брокера, что, вероятно, является причиной непрерывного сжатия и расширения ISR без автоматического восстановления.
  2. Истекло время ожидания реестра схемы. Я не знаю, как это повлияет на реестр схем.Я не вижу слишком большой нагрузки на этом сервере.Я что-то пропустил?Следует ли использовать балансировщик нагрузки для нескольких экземпляров схемы Registry в качестве аварийного переключения? .В теме __schemas всего 28 сообщений.Точное сообщение об ошибке RestClientException: регистрация операции истекло.Код ошибки: 50002
  3. Иногда скорость передачи сообщений превышает 100000 сообщений в секунду, иногда она падает до 2000 сообщений в секунду?размер сообщения может вызвать это?

    Чтобы решить некоторые из вышеуказанных проблем, мы увеличили количество брокеров и увеличили zookeeper.session.timeout.ms = 30000, но я не уверен, действительно ли это решило нашу проблему.проблема и если да, то как?.

У меня есть несколько вопросов:

  1. Достаточно ли хорош наш кластер для обработки такого большого количества данных.
  2. Есть ли что-то очевидное, чего нам не хватает?
  3. Как загрузить тестирование моей установки перед переходом на производственный уровень?
  4. Что может вызвать тайм-ауты сеансов между брокерами и реестром схемы.
  5. Лучший способ справиться с проблемой реестра схемы.

Сетевая нагрузка на одного из наших брокеров.

Network Bytes In one of our broker

Не стесняйтесь спрашивать дополнительную информацию.

...