Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 95347181F1 for ; Tue, 24 Nov 2015 10:47:03 +0000 (UTC) Received: (qmail 6084 invoked by uid 500); 24 Nov 2015 10:47:00 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 5791 invoked by uid 500); 24 Nov 2015 10:47:00 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 4489 invoked by uid 99); 24 Nov 2015 10:46:59 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Nov 2015 10:46:59 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 214DB180183 for ; Tue, 24 Nov 2015 10:46:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=tink.se Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id G3p2Fjeqg2k0 for ; Tue, 24 Nov 2015 10:46:46 +0000 (UTC) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id E50B623288 for ; Tue, 24 Nov 2015 10:46:45 +0000 (UTC) Received: by ykba77 with SMTP id a77so13652707ykb.2 for ; Tue, 24 Nov 2015 02:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tink.se; s=tink; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=UaijzEq/YIOVMjo4uWAiPl4NDDwDOMUnVScvBqcLY3Q=; b=FN+bFzsJEOaK5H4hqEfbqkEUvF0WM6es3PMrnbDSWakXHYzM/PkFsA+mK2mRZuCvxO 77Lp7Z1Dgpu1S1dw2H6+oXkFhgt5QSme7MoK0dAGtTOgryqiJq4cRb5CWTcAtoDMl91F ID4nkgDYVffsHm453Z4KE0pUWOwlK8kXsoN90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=UaijzEq/YIOVMjo4uWAiPl4NDDwDOMUnVScvBqcLY3Q=; b=eBHt+YeNQZEZf/rz74II82rnYsKtp+sDwMtSYRS1fmOOOmgpy1h08nySEbXPga50kJ +bM2nWu6Wc2hdwLkMW3EI/sJDY8XR1ER/8AM8d2fe/Mzmj8GLiFFcUKeaVRtVLinGFGS 2yaq7z1iKUuYLhBNsFujlw6FfwNjLWL85eaoHiuAD95A4FLRs5AeMDw0nL4HFQ1L4GDf SdKlMDWIBHscb3y/g/x+N7HbK8LStOuy/iLi0M6m5zf8eTo+obNWtSMIe9DdzWUfS+XU MtptzEXaxVb4EAbBVjeILcWTAojjlDy0SpbVsKIsEV48nWDF6Kdbfbo/EaoH7mRRpRaw gTWg== X-Gm-Message-State: ALoCoQn3T+TNYr67xYpiGiV2cb2g/qfd+LD8JOGaQZHqxgM+kNMXaQSzErq5tCqsZ4Ry3HLnun2X X-Received: by 10.13.204.82 with SMTP id o79mr26561636ywd.60.1448362004864; Tue, 24 Nov 2015 02:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.32.130 with HTTP; Tue, 24 Nov 2015 02:46:25 -0800 (PST) In-Reply-To: References: From: Jens Rantil Date: Tue, 24 Nov 2015 11:46:25 +0100 Message-ID: Subject: Re: Reelection takes a long time To: "" Content-Type: multipart/alternative; boundary=001a11482dcace8a070525470ebb --001a11482dcace8a070525470ebb Content-Type: text/plain; charset=UTF-8 Longer than 30 seconds (which is our general lock timeout in applications), but shorter than 3 minutes. I'd guess 2 minutes. I'll see if I can restart the master tonight to get some logs. /J Cheers, Jens On Mon, Nov 23, 2015 at 3:29 PM, Camille Fournier wrote: > What does "a bit too long" mean here? 10 seconds? Two minutes? Longer, > shorter? > > Any snippets from the log during election would also be helpful. > > Thanks > C > On Nov 23, 2015 7:49 AM, "Jens Rantil" wrote: > > > Hi, > > > > *Problem:* We are running a Zookeeper ensemble that takes a bit too long > > time before a new master is elected when the old one is brought down. > > > > *Question:* Which configuration settings do I need to change to decrease > > the time before a reelection occurs? tickTime and syncLimit? > > > > *Additionals:* The relevant (I think!) configuration we are running is: > > > > # The number of milliseconds of each tick > > tickTime=2000 > > # The number of ticks that the initial > > # synchronization phase can take > > initLimit=60 > > # The number of ticks that can pass between > > # sending a request and getting an acknowledgement > > syncLimit=30 > > > > I have previously increases the limits somewhat to accomodate for > zookeeper > > nodes not being able to come up due to too large snapshot. This could > > definitely be the reason why reelection takes longer time. > > > > Any input appreciated. > > > > Cheers, > > Jens > > > > -- > > Jens Rantil > > Backend engineer > > Tink AB > > > > Email: jens.rantil@tink.se > > Phone: +46 708 84 18 32 > > Web: www.tink.se > > > > Facebook Linkedin > > < > > > http://www.linkedin.com/company/2735919?trk=vsrp_companies_res_photo&trkInfo=VSRPsearchId%3A1057023381369207406670%2CVSRPtargetId%3A2735919%2CVSRPcmpt%3Aprimary > > > > > Twitter > > > -- Jens Rantil Backend engineer Tink AB Email: jens.rantil@tink.se Phone: +46 708 84 18 32 Web: www.tink.se Facebook Linkedin Twitter --001a11482dcace8a070525470ebb--