Кафка INVALID_FETCH_SESSION_EPOCH
Мы используем настройку брокера kafka с приложением kafka streams, которое работает с использованием облачного потока kafka Spring. Хотя кажется, что он работает нормально, мы получаем следующие сообщения об ошибках в нашем журнале:
2019-02-21 22:37:20,253 INFO kafka-coordinator-heartbeat-thread | anomaly-timeline org.apache.kafka.clients.FetchSessionHandler [Consumer clientId=anomaly-timeline-56dc4481-3086-4359-a8e8-d2dae12272a2-StreamThread-1-consumer, groupId=anomaly-timeline] Node 2 was unable to process the fetch request with (sessionId=1290440723, epoch=2089): INVALID_FETCH_SESSION_EPOCH.
Я искал в Интернете, но информации об этой ошибке не так много. Я предположил, что это может быть связано с разницей в настройках времени между брокером и потребителем, но обе машины имеют одинаковые настройки сервера времени.
Любая идея, как это можно решить?
Ответы 5
Существует концепция сеанса выборки, введенная в KIP-227 начиная с версии 1.1.0: https://cwiki.apache.org/confluence/display/KAFKA/KIP-227%3A+Introduce+Incremental+FetchRequests+to+Increase+Partition+Scalability.
Брокеры Kafka, которые являются последователями реплик, получают сообщения от лидера. Чтобы каждый раз не отправлять полные метаданные для всех разделов, в рамках одного сеанса выборки отправляются только те разделы, которые изменились.
Когда мы смотрим в код Кафки, мы видим пример, когда это возвращается:
if (session.epoch != expectedEpoch) {
info(s"Incremental fetch session ${session.id} expected epoch $expectedEpoch, but " +
s"got ${session.epoch}. Possible duplicate request.")
new FetchResponse(Errors.INVALID_FETCH_SESSION_EPOCH, new FetchSession.RESP_MAP, 0, session.id)
} else {
В общем, если у вас не тысячи разделов и, в то же время, это происходит не очень часто, то это не должно вас беспокоить.
какую версию Кафки вы используете?
Версия Кафки: 2.0.1 Идентификатор фиксации Кафки: fa14705e51bd2ce5
у вас есть идея, что вызывает это? Поможет ли опубликовать мои потребительские настройки ??
Возможно, у вас есть клиенты, которые считывают информацию с брокера во время ротации журналов в соответствии с графиком хранения; это также приведет к тому, что вы получите INVALID_FETCH_SESSION_EPOCH, поскольку рассматриваемый раздел больше не существует в сегменте журнала.
Это не проблема сети, ответ DanM является принятым.
Действительно, вы можете получить это сообщение, когда происходит прокрутка или удаление на основе удержания, как указано в комментариях дзен. Это не проблема, если это происходит не постоянно. Если да, проверьте настройки log.roll и log.retention.
Проверять их на что именно?
Проверьте, когда и как часто происходят события переноса/удержания.
Похоже, это может быть вызвано проблемой Кафка-8052, которая была исправлена в Kafka 2.3.0.
Недавно я обновил свои клиенты kafka, чтобы они соответствовали брокеру версии не ниже 2.3.0. Это действительно решило проблему, спасибо!
В нашем случае первопричиной был kafka Broker — несовместимость клиента. Если ваш кластер отстает от клиентской версии, вы можете столкнуться со всевозможными странными проблемами, такими как эта.
Наш брокер kafka работает на 1.x.x, а наш kafka-consumer — на 2.x.x. Как только мы понизили наш рейтинг spring-cloud-dependencies до Finchley.RELEASE, наша проблема была решена.
dependencyManagement {
imports {
mavenBom "org.springframework.cloud:spring-cloud-dependencies:Finchley.RELEASE"
}
}
Обновление версии клиента до 2.3 (та же версия от брокера) исправило это для меня.
Это сработало для меня. Мы использовали версию серверного брокера 2.3.0, но наши клиенты использовали 2.2.1. Обновление клиентов до версии 2.3.1 остановило эти INVALID_FETCH_SESSION_EPOCH журналы.
К сожалению, я не думаю, что это связано с проблемами с сетью, так как я сталкиваюсь с ними и при настройке локального докера: аномалия-временная шкала-2 | 2019-02-22 14:45:39,593 INFO anomaly-timeline-db8558f2-cb17-4a87-b4ba-fe0fd1c47ec0-StreamThread-1 org.apache.kafka.clients.FetchSessionHandler [Consumer clientId=anomaly-timeline-db8558f2-cb17 -4a87-b4ba-fe0fd1c47ec0-StreamThread-1-consumer, groupId=anomaly-timeline] Узел 1001 не смог обработать запрос на выборку с (sessionId=593140062, эпоха=65): INVALID_FETCH_SESSION_EPOCH.