From dev-return-76282-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Sun Nov 25 09:02:50 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B1828180674 for ; Sun, 25 Nov 2018 09:02:49 +0100 (CET) Received: (qmail 75947 invoked by uid 500); 25 Nov 2018 08:02:48 -0000 Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@zookeeper.apache.org Delivered-To: mailing list dev@zookeeper.apache.org Received: (qmail 75936 invoked by uid 99); 25 Nov 2018 08:02:47 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Nov 2018 08:02:47 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 6590DDFEF4; Sun, 25 Nov 2018 08:02:47 +0000 (UTC) From: lvfangmin To: dev@zookeeper.apache.org Reply-To: dev@zookeeper.apache.org References: In-Reply-To: Subject: [GitHub] zookeeper issue #703: [ZOOKEEPER-1818] Correctly handle potential inconsiste... Content-Type: text/plain Message-Id: <20181125080247.6590DDFEF4@git1-us-west.apache.org> Date: Sun, 25 Nov 2018 08:02:47 +0000 (UTC) Github user lvfangmin commented on the issue: https://github.com/apache/zookeeper/pull/703 @anmolnar following are my understanding about the acceptedEpoch, currentEpoch and electionEpoch: * acceptedEpoch : the previous epoch we accepted so far, usually is the epoch is the highest zxid on that server. * currentEpoch : the current epoch after syncing with the new leader, it's based on the maximum acceptedEpoch in the quorum, and usually it's the max(acceptedEpoch) + 1. The currentEpoch is used as the peerEpoch in the leader election, as we know (sid, zxid, peerEpoch) are the set used to decide a leader. * electionEpoch : not part of the factors to decide leader, but it's used as a logical clock to avoid considering a vote delayed from a while ago. Basically, we know there is a corner case where the learner may not update it's zxid, peerEpoch, and electionEpoch after leader election (check the new comment I added Leader.updateElectionVote), peerEpoch is fixed with a hack solution, but we cannot easily update the zxid and electionEpoch, so we try to ignore it. But IGNOREVALUE introduced will have compatible issue when rolling upgrade ensemble, that's why we introduced version in notification, and only compare id or peerEpoch based on version. ---