私たちはkafkaブローカーセットアップでkafkaストリームアプリケーションを使用し、Springクラウドストリームkafkaを使用して実行します。正常に実行されているように見えますが、次のようになります。ログのエラーステートメント:
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.
インターネットを検索しましたが、このエラーに関する情報はあまりありません。ブローカーとコンシューマーの時間設定の違いが関係しているのではないかと思いましたが、両方のマシンのタイムサーバー設定は同じです。
これを解決する方法はありますか?
1.1.0リリース以降、KIP-227内で導入されたフェッチセッションの概念があります。 https://cwiki.Apache.org/confluence/display/KAFKA/KIP-227%3A+Introduce+Incremental+FetchRequests + to + Increase + Partition + Scalability
レプリカのフォロワーであるKafkaブローカーは、リーダーからメッセージをフェッチします。すべてのパーティションに対して毎回完全なメタデータを送信しないようにするために、変更されたパーティションのみが同じフェッチセッション内で送信されます。
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 {
一般に、数千のパーティションがなく、これが頻繁に発生しない場合でも、心配する必要はありません。
これは Kafka-8052 の問題が原因である可能性があるようです。これはKafka 2.3.0で修正されました。
実際、このメッセージは、ローリングまたは保持ベースの削除が発生したときに表示される可能性があります。コメントでzenが指摘されています。いつも起こらなくても問題ありません。ある場合は、log.roll
およびlog.retention
構成。
クライアントバージョンを2.3(ブローカーからの同じバージョン)に更新すると、修正されます。
私たちのケースでは、根本的な原因はkafkaブローカー-クライアントの非互換性です。クラスターがクライアントバージョンの背後にある場合、このようなあらゆる種類の奇妙な問題が発生する可能性があります。
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"
}
}