[ https://issues.apache.org/jira/browse/KAFKA-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585402#comment-13585402 ]
Guozhang Wang commented on KAFKA-763: ------------------------------------- About the "the replicas may not be identical for a chunk of offsets" issue, if we do not want to have any non-resolvable divergence, the following may fix it: When an non-ISR replica is elected as the leader (assuming itself could know that from ZK, but I'm not sure if it is true), the new leader records its current earliest/latest offset, whose messages are still in sync with the old leader. When an follower wakes up and request LO and FO, the leader returns the recorded LO and FO instead of its current earliest/latest offset. But this could result in lots of fetching also. If we choose availability over consistency in this case, we can just live with it. > Add an option to replica from the largest offset during unclean leader > election > ------------------------------------------------------------------------------- > > Key: KAFKA-763 > URL: https://issues.apache.org/jira/browse/KAFKA-763 > Project: Kafka > Issue Type: Improvement > Components: core > Affects Versions: 0.8 > Reporter: Jun Rao > Assignee: Swapnil Ghike > Priority: Blocker > Labels: p2 > Attachments: kafka-763_v1.patch > > > If there is an unclean leader election, a follower may have an offset out of > the range of the leader. Currently, the follower will delete all its data and > refetch from the smallest offset of the leader. It would be useful to add an > option to let the follower refetch from the largest offset of the leader > since refetching from the smallest offset may take some time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira