如果其副本中的一个副本停止以跟上复制因素，那么kafka会创建一个新的关注者

Question

Below is my partition information for the topic xx_json_topic .This is a Kafka cluster with three nodes .

All nodes up :

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

At this point.. if i bring down the node "node-1" ..It looks like below :

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

My question is ..if kafka knows that the node-1 is down and it needs to maintain the replication factor ,wouldn't it make node 3 a replica for partition-1 && node-2 a replica for partition-0 then make node-3 and node-2 part of their Isr ?

Or you think Kafka doesn't promise that... If replication factor is 2 ..It doesn't mean that data will be available in atleast 2 nodes at all time(---like consistency level in Cassandra) .

Answer 1

You are correct that this is not the way replication factor is handled in Kafka. When you specify a replication factor of 2 for a topic, the partitions of that topic are created on 2 brokers (and the cluster controller attempts to spread them out over the cluster). At that time, one becomes the leader, and one becomes the follower. This is not a guarantee that there will always be two copies of the partitions, it only specifies that two replicas are created, and the brokers will notify you (via the underreplicated partitions count mbean) if all replicas do not exist.

Kafka does not perform any automatic repair of the cluster, with the exception that if you have multiple replicas for a partition, and the leader replica becomes unavailable, one of the followers will take over as leader. When that leader comes back, however, it will not resume leadership (it becomes a follower). In the same way, the cluster will not create new replicas. This can be a very resource-intensive operation, as a lot of data needs to be moved across the network to the new replica.

While there is an option to perform automatic leader rebalancing, there is no equivalent option to perform automatic replica creation.