2017-05-31 4 views
0

kafkaブローカーと飼育係のドッキング画像があります。現在はz1, b1, b2と呼んでいます。 彼らはように2台の物理サーバs1s2上に展開されています
s1が自分docker-compose.ymlファイルでb2Docker、Kafka - リモートブローカー間で複製が行われない

z1b1
s2が含まれて含まれ、飼育係は、次のようにポートを設定しています

- 2181:2181 
- 2888:2888 
- 3888:3888 

次のようにブローカー:

- 9092:9092 

トピックは--replication-factor 2--partitions 4と作成できます。
データは常にトピックにプッシュされますが、それでも問題が発生します。
トピック作成の直後にkafka-topics --describe --topic <name_of_topic> --zookeeper <zookeeperIP:port>を実行すると、すべてがinsyncになります。
2回目の実行で(短い遅延で)、b1は、からb2パーティション・レプリカを削除しますが、はinsyncからb1パーティション・レプリカを削除しません。 b1からのserver.logで

は、これらの例外の多くが表示されます。

WARN [ReplicaFetcherThread-0-1], Error in fetch [email protected]de3 (kafka.server.ReplicaFetcherThread) 
java.io.IOException: Connection to ef447651b07a:9092 (id: 1 rack: null) failed 
    at kafka.utils.NetworkClientBlockingOps$.awaitReady$1(NetworkClientBlockingOps.scala:83) 
    at kafka.utils.NetworkClientBlockingOps$.blockingReady$extension(NetworkClientBlockingOps.scala:93) 
    at kafka.server.ReplicaFetcherThread.sendRequest(ReplicaFetcherThread.scala:248) 
    at kafka.server.ReplicaFetcherThread.fetch(ReplicaFetcherThread.scala:238) 
    at kafka.server.ReplicaFetcherThread.fetch(ReplicaFetcherThread.scala:42) 
    at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:118) 
    at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:103) 
    at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:63) 

スワップのリーダーシップは最後のものだけ、彼らがシャットダウンして、再度起動しているとして、ブローカーb1b2の間で動作しますが、オンラインはトピックを完全に制御しています。つまり、他のブローカーがオンラインに戻ったとしても、すべてのパーティションのリーダーであり、insyncは1つだけです。

すべてのデータを消去し、ブローカーと飼い主の両方をリセットしようとしましたが、問題は解決しません。

パーティションが正しく複製されないのはなぜですか?

答えて

0

私はそれを理解しました。 Michael G. Noll氏によると、ネットワークに問題がありました。
まず、手動でポートを手動でマッピングしないで、代わりにhostネットワークを使用します。管理が簡単です。
Secenodaryは、B1とB2は、リスナーがそのように設定していた:

listeners=PLAINTEXT://:9092 

彼らの両方が指定されていないIPアドレスを持っていないので、0.0.0.0がデフォルトで使用された、彼らの両方が耳を傾け、ZooKeeperのために同じ接続情報をプッシュとしてcollissionがあったが、 。

最終的な構成
b1b2docker-compose.yml使用hostネットワーク:

network_mode: "host" 

b1 server.properties` - リスナー:

listeners=PLAINTEXT://<s1_IP>:9092 

b2 server.properties` - リスナー:

listeners=PLAINTEXT://<s2_IP>:9092 

すべての処理が正常に行われ、ブローカの再起動時でもすべてのレプリケーションが機能します。 データを正しく生成して消費することができます。

2

ブローカーのように見えますb1b2はお互いに話すことができません。これはDocker関連のネットワークの問題を示しています(一般的にDockerのネットワーキングの問題は一般的です)。

さらに詳しい情報を共有する必要があります。ファイルの内容は、例えば、docker-compose.ymlのものである。 Dockerfileイメージの作成に使用します。また、なぜあなたは2つのブローカーのために異なるイメージを作成したのだろうか、なぜなら、通常は単一のカフカブローカーイメージが必要なだけで、イメージから複数のコンテナー(目的のブローカーにつき1つ)を起動するだけです。

+0

お返事ありがとうございます。ドッカーファイルを貼り付けることはできません。ネットワークの設定だけが問題になるため、無意味です。 docker-compose.ymlのポートは問題のようにマッピングされ、zookeepersのクライアントポートは2181に設定されています。両方のカフカブローカーにはリスナー= PLAINTEXT://127.0.0.1:9092があります。私はまた、ブローカが0.0.0.0:9092と0.0.0.0:9093にマッピングされるように、ipと変更ポートを指定しないようにしましたが、問題は依然として続きます。私はPLAINTEXTのみを指定しているので、REPLICATION listenerについても読んでください。 – milkamar

+0

あなたの環境は何ですか?あなたはこれを実行しますか? MacまたはKubernetesのローカルでLinux VMを搭載したドッカーマシンを使用していますか?これはDockerのネットワーク機能にどのような影響を与えますか?また、Dockerの設定に関する質問を続けているので、dockerファイルを表示するのは無意味ではありません。また、完全な画像が表示されないときにデバッグするのは困難です。ホストネットワークモードまたはブリッジネットワークモード?どのようにコンテナの 'ホスト名'を設定しますか? –

関連する問題