4

以下は、トピックxx_json_topicのパーティション情報です。これは、3 つのノードを持つ Kafka クラスターです。

すべてのノードが稼働中:

Topic: xx_json_topic    PartitionCount:4    ReplicationFactor:2    Configs:
Topic: xx_json_topic    Partition: 0    Leader: 1   Replicas: 3,1   Isr: 3,1
Topic: xx_json_topic    Partition: 1    Leader: 2   Replicas: 1,2   Isr: 2,1
Topic: xx_json_topic    Partition: 2    Leader: 2   Replicas: 2,3   Isr: 2,3
Topic: xx_json_topic    Partition: 3    Leader: 3   Replicas: 3,2   Isr: 2,3

この時点で..ノード「node-1」を停止すると..以下のようになります。 

Topic: xx_json_topic    PartitionCount:4    ReplicationFactor:2    Configs:
Topic: xx_json_topic    Partition: 0    Leader: 3   Replicas: 3,1   Isr: 3
Topic: xx_json_topic    Partition: 1    Leader: 2   Replicas: 1,2   Isr: 2
Topic: xx_json_topic    Partition: 2    Leader: 2   Replicas: 2,3   Isr: 2,3
Topic: xx_json_topic    Partition: 3    Leader: 3   Replicas: 3,2   Isr: 2,3

私の質問は、ノード 1 がダウンしていて、レプリケーション ファクターを維持する必要があることを kafka が認識している場合、ノード 3 をパーティション 1 のレプリカにし、ノード 2 をパーティション 0 のレプリカにしないでください。 -3 と node-2 は Isr の一部ですか?

または、Kafka はそれを約束していないと思います...レプリケーション係数が 2 の場合..データが常に少なくとも 2 つのノードで利用できるという意味ではありません (---Cassandra の一貫性レベルのように) 。

4

1 に答える 1

4

これは、Kafka でレプリケーション ファクターが処理される方法ではないことは間違いありません。トピックに 2 のレプリケーション ファクターを指定すると、そのトピックのパーティションが 2 つのブローカーに作成されます (クラスター コントローラーはそれらをクラスター全体に分散させようとします)。その時、一方がリーダーになり、一方がフォロワーになります。これは、パーティションの 2 つのコピーが常に存在することを保証するものではありません。2 つのレプリカが作成されることを指定するだけであり、すべてのレプリカが存在しない場合、ブローカーは (複製されていないパーティションのカウント mbean を介して) 通知します。

Kafka はクラスターの自動修復を実行しませんが、パーティションに複数のレプリカがあり、リーダー レプリカが使用できなくなった場合、フォロワーの 1 つがリーダーとして引き継がれます。ただし、そのリーダーが戻ってきても、再びリーダーになることはありません (フォロワーになります)。同様に、クラスターは新しいレプリカを作成しません。これは、大量のデータをネットワーク経由で新しいレプリカに移動する必要があるため、リソースを大量に消費する操作になる可能性があります。

リーダーの自動リバランスを実行するオプションはありますが、レプリカの自動作成を実行する同等のオプションはありません。

于 2015-09-15T17:57:20.803 に答える