Search code examples
apache-kafkakafka-topic

Does Kafka maintain the In-sync replication factor after leader goes down?

Can someone please explain the in-sync replication factor maintainance in Kafka in the below scenario:

Scenario:

  1. Consider, initially we have replication factor as 3.
  2. In Kafka if the leader goes down one of the in-sync replicas becomes the new leader.

so, for the new leader(one of the in-sync replica) does Kafka again maintain the replication factor of 3.

Solution

  • Hoping to add more clarity on Kafka notations: There is no "in-sync replication factor". Each topic has a "replication factor" and a seperate list of "in-sync replicas" (also known as ISR). In a healthy cluster the replication factor and the number the number of in-sync replicas match, but as soon as one broker crashes those numbers could deviate as you will have out of sync replicas.

    "so, for the new leader(one of the in-sync replica) does Kafka again maintain the replication factor of 3."

    Yes (and no). Kafka will stick to the replication factor of 3. However, it expectes the crashed broker to become available again. During that time your topic will have

    • a new leader (as you already mentioned in your second bullet point)
    • a replication-factor of 3
    • only two in-sync replicas

    So, although you have a replication-factor of 3, your topic will have one out of sync replicas.

    Until the broker has restart, it now depends on the KafkaProducer configurations acks and min.insync.replicas if a producer can still write data to the topic successfully. The description of min.insync.replicas gives some more details:

    "When a producer sets acks to "all" (or "-1"), min.insync.replicas specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful."

    The Kafka documentation on Balancing leadership provides some background what happens with the partition leader:

    Whenever a broker stops or crashes, leadership for that broker's partitions transfers to other replicas. When the broker is restarted it will only be a follower for all its partitions, meaning it will not be used for client reads and writes.

    To avoid this imbalance, Kafka has a notion of preferred replicas. If the list of replicas for a partition is 1,5,9 then node 1 is preferred as the leader to either node 5 or 9 because it is earlier in the replica list. By default the Kafka cluster will try to restore leadership to the restored replicas. This behaviour is configured with:

    auto.leader.rebalance.enable=true