Return-Path: X-Original-To: apmail-kafka-dev-archive@www.apache.org Delivered-To: apmail-kafka-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 32180EE9B for ; Sun, 24 Feb 2013 15:58:20 +0000 (UTC) Received: (qmail 61104 invoked by uid 500); 24 Feb 2013 15:58:19 -0000 Delivered-To: apmail-kafka-dev-archive@kafka.apache.org Received: (qmail 60849 invoked by uid 500); 24 Feb 2013 15:58:14 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 60795 invoked by uid 99); 24 Feb 2013 15:58:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Feb 2013 15:58:12 +0000 Date: Sun, 24 Feb 2013 15:58:12 +0000 (UTC) From: "Guozhang Wang (JIRA)" To: dev@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (KAFKA-763) Add an option to replica from the largest offset during unclean leader election MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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