Потоки Кафки - не удалось сбалансировать ошибку - PullRequest
Новая
       5

Потоки Кафки - не удалось сбалансировать ошибку

0 голосов
/ 21 января 2019

У меня есть базовое приложение Kafka Streams, которое читает из in_topic, выполняет скользящий агрегат и выполняет объединение для публикации в out_topic. Это работало нормально в течение нескольких недель, но сегодня утром оно рухнуло и больше не запускается. Я не думаю, что это имеет какое-либо отношение к коду. Журнал до ошибки: 

2019-01-21 17:46:32,803 localhost org.apache.kafka.clients.producer.KafkaProducer: [Producer clientId=rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1-0_0-producer, transactionalId=rtt-healthscore-stream-0_0] Instantiated a transactional producer.
2019-01-21 17:46:32,803 localhost org.apache.kafka.clients.producer.KafkaProducer: [Producer clientId=rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1-0_0-producer, transactionalId=rtt-healthscore-stream-0_0] Overriding the default acks to all since idempotence is enabled.
2019-01-21 17:46:32,818 localhost org.apache.kafka.common.utils.AppInfoParser: Kafka version : 2.0.0
2019-01-21 17:46:32,818 localhost org.apache.kafka.common.utils.AppInfoParser: Kafka commitId : 3402a8361b734732
2019-01-21 17:46:32,832 localhost org.apache.kafka.clients.producer.internals.TransactionManager: [Producer clientId=rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1-0_0-producer, transactionalId=rtt-healthscore-stream-0_0] ProducerId set to -1 with epoch -1
2019-01-21 17:47:32,833 localhost org.apache.kafka.streams.processor.internals.StreamThread: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] Error caught during partition assignment, will abort the current process and re-throw at the end of rebalance: {}
org.apache.kafka.common.errors.TimeoutException: Timeout expired while initializing transactional state in 60000ms.
2019-01-21 17:47:32,843 localhost org.apache.kafka.streams.processor.internals.StreamThread: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] partition assignment took 60062 ms.
    current active tasks: []
    current standby tasks: []
    previous active tasks: []

2019-01-21 17:47:32,845 localhost org.apache.kafka.streams.processor.internals.StreamThread: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] State transition from PARTITIONS_ASSIGNED to PENDING_SHUTDOWN
2019-01-21 17:47:32,845 localhost org.apache.kafka.streams.processor.internals.StreamThread: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] Shutting down
2019-01-21 17:47:32,860 localhost org.apache.kafka.streams.processor.internals.StreamThread: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] State transition from PENDING_SHUTDOWN to DEAD
2019-01-21 17:47:32,860 localhost org.apache.kafka.streams.KafkaStreams: stream-client [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804] State transition from REBALANCING to ERROR
2019-01-21 17:47:32,860 localhost org.apache.kafka.streams.KafkaStreams: stream-client [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804] All stream threads have died. The instance will be in error state and should be closed.
2019-01-21 17:47:32,860 localhost org.apache.kafka.streams.processor.internals.StreamThread: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] Shutdown complete
Exception in thread "rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1" org.apache.kafka.streams.errors.StreamsException: stream-thread [rtt-healthscore-stream-7d679951-913b-4976-a43e-0b437c22c804-StreamThread-1] Failed to rebalance.
    at org.apache.kafka.streams.processor.internals.StreamThread.pollRequests(StreamThread.java:870)
    at org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:810)
    at org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:767)
    at org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:736)
Caused by: org.apache.kafka.common.errors.TimeoutException: Timeout expired while initializing transactional state in 60000ms.

Ни одна из настроек / конфигов kafka не изменилась, и все брокеры доступны. Моя Кафка версия 2.0. Я могу читать с in_topic с консоли-потребителя, поэтому все до этого приложения в порядке. Вся помощь приветствуется.

Ответы [ 2 ]

0 голосов
/ 20 февраля 2019

Мы также получили эти ошибки после обновления до 2.1 (и я думаю также, когда ранее мы обновились до более ранних версий.)

Мы работаем в среде kubernetes, где после непрерывного обновления брокеры могут менять IP-адрес. Из журнала брокера: 

[2019-02-20 02:20:20,085] WARN [TransactionCoordinator id=1001] Connection 
to node 0 (khaki-joey-kafka-0.khaki-joey-kafka-headless.hyperspace-dev/10.233.124.181:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)
[2019-02-20 02:20:57,205] WARN [TransactionCoordinator id=1001] Connection to node 1 (khaki-joey-kafka-1.khaki-joey-kafka-headless.hyperspace-dev/10.233.122.67:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)

Я вижу, что координатор транзакций все еще использует устаревшие IP-адреса для двух брокеров, которые были перезапущены после него (через день после обновления).

Возможные варианты:

  • Как сказал в этом ответе , выключите Ровно Один раз для вашего стримера. Затем он не использует транзакции, и все, кажется, работает нормально. Бесполезно, если вам требуется EOS или какой-либо другой клиентский код, требующий транзакций.
  • перезапустите всех брокеров, которые сообщают о предупреждениях, чтобы заставить их повторно разрешить IP-адрес. Их нужно будет перезапустить так, чтобы они сами не меняли IP-адрес. Обычно не возможно в kubernetes.

Дефект поднят Выпуск KAFKA-7958 - Транзакции прерываются с размещенными брокерами kubernetes

Обновление 2017-02-20 Это может быть решено в Kafka 2.1.1 (Confluent 5.1.2 ), выпущенном сегодня. Смотрите связанную проблему.

0 голосов
/ 22 января 2019

В нашем проекте произошел тот же сбой тайм-аута после обновления до Kafka 2.1, и мы пока не знаем причину.

Наш временный обходной путь - отключить конфигурацию exactly_once, которая пропускает исходное состояние транзакции.

...