Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B24AF2009F8 for ; Fri, 3 Jun 2016 22:30:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id B0E0C160A49; Fri, 3 Jun 2016 20:30:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 07896160A3B for ; Fri, 3 Jun 2016 22:30:07 +0200 (CEST) Received: (qmail 94357 invoked by uid 500); 3 Jun 2016 20:30:07 -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 94346 invoked by uid 99); 3 Jun 2016 20:30:07 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jun 2016 20:30:07 +0000 Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id C0C2E1A0044 for ; Fri, 3 Jun 2016 20:30:06 +0000 (UTC) Received: by mail-io0-f170.google.com with SMTP id p194so88578990iod.1 for ; Fri, 03 Jun 2016 13:30:06 -0700 (PDT) X-Gm-Message-State: ALyK8tIRHWhxIVqZKvZNkS6o8/fFtv1sKFGds8FzXi37GmhzBDdNCUfN9aRRVwCg+liyBo1xwDp+vI9PXgmMtw== X-Received: by 10.36.62.133 with SMTP id s127mr2239393its.98.1464985806037; Fri, 03 Jun 2016 13:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.98 with HTTP; Fri, 3 Jun 2016 13:30:05 -0700 (PDT) In-Reply-To: <6d6a1e85-4741-6aea-22ca-ae113fe0803f@elyograg.org> References: <3617775A-664D-4915-A5C2-09204C2F7D12@icloud.com> <6d6a1e85-4741-6aea-22ca-ae113fe0803f@elyograg.org> From: Camille Fournier Date: Fri, 3 Jun 2016 16:30:05 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: zookeeper deployment strategy for multi data centers To: "user@zookeeper.apache.org" Content-Type: multipart/alternative; boundary=001a113fe08c9213990534659627 archived-at: Fri, 03 Jun 2016 20:30:08 -0000 --001a113fe08c9213990534659627 Content-Type: text/plain; charset=UTF-8 2 servers is the same as 1 server wrt fault tolerance, so yes, you are correct. If they want fault tolerance, they have to run 3 (or more). On Fri, Jun 3, 2016 at 4:25 PM, Shawn Heisey wrote: > On 6/3/2016 1:44 PM, Nomar Morado wrote: > > Is there any settings to override the quorum rule? Would you know the > > rationale behind it? Ideally, you will want to operate the application > > even if at least one data center is up. > > I do not know if the quorum rule can be overridden, or whether your > application can tell the difference between a loss of quorum and > zookeeper going down entirely. I really don't know anything about > zookeeper client code or zookeeper internals. > > From what I understand, majority quorum is the only way to be > *completely* sure that cluster software like SolrCloud or your > application can handle write operations with confidence that they are > applied correctly. If you lose quorum, which will happen if only one DC > is operational, then your application should go read-only. This is what > SolrCloud does. > > I am a committer on the Apache Solr project, and Solr uses zookeeper > when it is running in SolrCloud mode. The cloud code is handled by > other people -- I don't know much about it. > > I joined this list because I wanted to have the ZK devs include a > clarification in zookeeper documentation -- oddly enough, related to the > very thing we are discussing. I wanted to be sure that the > documentation explicitly mentioned that three serversare required for a > fault-tolerant setup. Some SolrCloud users don't want to accept this as > a fact, and believe that two servers should be enough. > > Thanks, > Shawn > > --001a113fe08c9213990534659627--