1. イベントの背景
クラスター サーバーのクラッシュにより、多くのビッグ データ コンポーネントが異常にシャットダウンされ、サーバーとクラスターを再起動した後、すべてのコンポーネントは正常な状態になりましたが、flink タスクは正常に実行できませんでした。
2. 問題となる現象
サーバーを再起動した後は、すべてが正常であるように見え、コンポーネントは良好な状態にあります。
ただし、flink タスクの送信時に問題が発見され、カナリア テストが時々失敗することが Zookeeper から報告されました。
次に、flink 実行ログを確認して、トピック メタデータの取得のタイムアウトというエラーを見つけ、すべてのタスクがこれを報告しました。
3. 位置決めの問題
問題を解決するには、問題の根本原因を見つけて、zookeeper と組み合わせてカナリア テストの失敗を時々報告する必要があります。ネットワークの問題 (サーバーの負荷がかかっている) であると考えられますが、方法はありません
。それを証明するには、他の方法を考え続けるしかありません。コマンドラインを使用して、サーバー側でコンシューマを起動します。エラーはまだ報告されています
。ネットワークの問題ではないことがわかりました。kafka メタデータに問題があるはずです。
そこで、コマンドを使用してそれぞれの情報を表示しますトピック。
kafka-topics --describe --zookeeper node3:2181
結果は、すべてのトピックが正常であることを示した
ので、新しいトピックを作成し、それが消費できるかどうかを確認してみましたが、結果も No で、上の図のエラーが報告されました。
そこで、zookeeperに保存されているkafkaクラスタ情報に問題があるのではないかと考えたところ、最終的にzookeeper上の/controllerファイルに記録されている情報が実際の情報と一致していないことが判明した。
4. 問題を解決する
1. Kafka クラスター サービスを終了します。2. /controller ファイルを削除します。3. Zookeeper クラスターを再起動します。 4. Kafka クラスター サービスを開始します。 5. flink タスクを再送信します。 6. 問題を解決します。
5. 拡張
/controllerファイル関数
Kafka クラスターでは、コントローラーとして選ばれるのは 1 つのブローカーのみであり、各ブローカーはコントローラーになる機会があり、クラスター内のパーティション、コピー、障害検出、回復の管理を担当します。ブローカーが失敗したときに新しいコントローラーがすぐに再選択されるようにするために、Kafka は Zookeeper を使用してコントローラー情報を保存および管理します。したがって、/controller ファイルの内容は非常に重要であり、これにより、Kafka ブローカーと他のクライアントが現在のコントローラーがどのブローカーであるかを認識し、コントローラーと通信してさまざまなタスクをタイムリーに処理できるようになります。
具体的には、Kafka は現在のコントローラーの ID とアドレス情報を Zookeeper の /controller ノードに保存します。この情報には他のブローカーやクライアントがアクセスできるため、コントローラーと通信して、パーティションやレプリカの作成や削除など、必要な管理タスクを実行できます。
さらに、Kafka は Zookeeper を使用して、パーティションやレプリカの割り当て情報、コンシューマー グループのオフセット情報など、クラスター管理に関連する他のメタデータも保存します。